3 ms·

Hm, I haven't heard about that being an issue. If you can dig up the thread, I'd be glad to take a look.

by grinich 11y ago

darklajid 11y ago
Rummaging a bit I came up with the two comments at the bottom of the post. As I said - this was the first time I read about Nylas. When I see something potentially shiny I tend to react the same way as if I'd view an Amazon product listing: Scroll down, look at negative reviews.. So - the threads below seem to complain that the sync server has no authentication schema whatsoever (seems to be true after skimming GH/the link above) and - this is what I'm really curious about - even claims that you wouldn't accept free contributions to implement that. What I'm trying to ask, I guess: 1) Why no authentication for the sync server? 2) Are you really against any such contributions, if you don't intend to build those yourself? 3) Do you have any recipes/ideas/reports from happy users how you'd secure the sync-server in its current state, in a "let's play" deployment? 1: https://news.ycombinator.com/item?id=11061717 https://news.ycombinator.com/item?id=11061717 2: https://news.ycombinator.com/item?id=11122802 https://news.ycombinator.com/item?id=11122802
- grinich 11y ago
  I think these are actually two different questions. One is asking about new auth APIs so you don't need to run a script to connect accounts. We're working on that! The second is about how to do API authentication, i.e. how API requests are secured. The sync engine just provides all API data as a service, namespaces by account ID. Developers need to "secure" this by either running it behind a VPN, adding a proxy layer like Nginx, wrapping API calls in their own application layer, or dozens of other solutions. Everyone does this differently so it doesn't make sense to include as part of the default sync engine. The simplest version is probably to just block access to `/accounts` for external users and treat those account ids as authentication secrets. (They're just opaque long strings.) We're not against contributions, and nobody has actually built an auth system and submitted a PR.

Hm, I haven't heard about that being an issue. If you can dig up the thread, I'd be glad to take a look.

by grinich 11y ago

Hm, I haven't heard about that being an issue. If you can dig up the thread, I'd be glad to take a look.

Rummaging a bit I came up with the two comments at the bottom of the post. As I said - this was the first time I read about Nylas. When I see something potentially shiny I tend to react the same way as if I'd view an Amazon product listing: Scroll down, look at negative reviews.. So - the threads below seem to complain that the sync server has no authentication schema whatsoever (seems to be true after skimming GH/the link above) and - this is what I'm really curious about - even claims that you wouldn't accept free contributions to implement that. What I'm trying to ask, I guess: 1) Why no authentication for the sync server? 2) Are you really against any such contributions, if you don't intend to build those yourself? 3) Do you have any recipes/ideas/reports from happy users how you'd secure the sync-server in its current state, in a "let's play" deployment? 1: https://news.ycombinator.com/item?id=11061717 https://news.ycombinator.com/item?id=11061717 2: https://news.ycombinator.com/item?id=11122802 https://news.ycombinator.com/item?id=11122802

grinich 11y ago
I think these are actually two different questions. One is asking about new auth APIs so you don't need to run a script to connect accounts. We're working on that! The second is about how to do API authentication, i.e. how API requests are secured. The sync engine just provides all API data as a service, namespaces by account ID. Developers need to "secure" this by either running it behind a VPN, adding a proxy layer like Nginx, wrapping API calls in their own application layer, or dozens of other solutions. Everyone does this differently so it doesn't make sense to include as part of the default sync engine. The simplest version is probably to just block access to `/accounts` for external users and treat those account ids as authentication secrets. (They're just opaque long strings.) We're not against contributions, and nobody has actually built an auth system and submitted a PR.