4 ms·

so bots can sign up easily: while (true) { hoodie.account.signUp(_.uniqueId() + '@gmail.com', _.uniqueId()) } great effort though, but I still don't think y

so bots can sign up easily: while (true) { hoodie.account.signUp(_.uniqueId() + '@gmail.com', _.uniqueId()) } great effort though, but I still don't think you've got client/server separation right. we've built something very similar over a year ago: an offline client db backed by memory/websql/indexed-db that replicates with dynamo-db so the app works offline. Looked at Couch/Pouch solution but decided against Couch for performance reasons. Might open source it later once we figure out the user management/security bit. I still find the existing solutions (including Firebase) not ideal.

Mahn 14y ago
I was thinking there might be some sort of throttling/banning mechanism within the signUp function itself, but then being client based that could be easily circumvented unless there's some server side logic aswell. I wonder whether there's a sane way to handle this client side short of minify and/or obfuscate the code and hope for the best.
- espylaub 14y ago
  Let me refer to a great answer Lazare gave further up (more generally about sync, but very useful nonetheless): https://news.ycombinator.com/item?id=5517632 https://news.ycombinator.com/item?id=5517632
espylaub 14y ago
You have the option of requiring user confirmation via email (right now users are auto-confirmed by default). Non-confirmed users only write to their localStorage (so they can still use the app pre signup), but nothing (apart from their tiny user object) is synced to the remote DB, nothing is parsed by workers, etc. Then write a worker to cull unconfirmed user objects after a while, and you should be fine. I don't know about additional throttling though, but it seems very doable. Disclaimer: this isn't my area of expertise, but the rest of the Hoodie team are quite confident about this issue, and I trust them. The other two are currently travelling, but if you have more questions, I'm sure one of them will get back to you with more in-depth info.

Mahn 14y ago

I was thinking there might be some sort of throttling/banning mechanism within the signUp function itself, but then being client based that could be easily circumvented unless there's some server side logic aswell. I wonder whether there's a sane way to handle this client side short of minify and/or obfuscate the code and hope for the best.

espylaub 14y ago
Let me refer to a great answer Lazare gave further up (more generally about sync, but very useful nonetheless): https://news.ycombinator.com/item?id=5517632 https://news.ycombinator.com/item?id=5517632

espylaub 14y ago

You have the option of requiring user confirmation via email (right now users are auto-confirmed by default). Non-confirmed users only write to their localStorage (so they can still use the app pre signup), but nothing (apart from their tiny user object) is synced to the remote DB, nothing is parsed by workers, etc. Then write a worker to cull unconfirmed user objects after a while, and you should be fine. I don't know about additional throttling though, but it seems very doable. Disclaimer: this isn't my area of expertise, but the rest of the Hoodie team are quite confident about this issue, and I trust them. The other two are currently travelling, but if you have more questions, I'm sure one of them will get back to you with more in-depth info.