Hacker News Reader

Comment by primitivesuave | Hacker News Reader

Giving full email privileges to the client is a terrible idea. Even if you do rate limiting, you're essentially allowing anyone to get your mail server(s) blacklisted and all future mail from anyone marked as spam.

In general, most people would be naturally apprehensive about federating their entire user authentication system through a third party. However, I suppose that by using hoodie you are supporting a group of people whose only job is to ensure security and fix vulnerabilities in your login system. It's also open-source, so you can vet it for yourself.

The JS library needs more work though - I could think of several basic use cases that it can't handle. It would also be great to see some full examples. Overall this is very cool stuff.

View on HN

Hoodie doesn't provide any email privileges in it's core. There is an email plugin that does that, but it's just a showcase and we would not recommend to use that in a production app. The plugin is maybe 10 lines of code, you can easily use that as base and put all the security in it that you would do in a REST API as well.

I'd be also very interested in your basic use cases that you think Hoodie couldn't handle. It would certainly be great input for the project.

"There is an email plugin that does that, but it's just a showcase and we would not recommend to use that in a production app."

You do realize that by putting it in your documentation, you're encouraging people to use it.

We also encourage people not to use Hoodie in production, yet :)

What @gr2m means: there is no reason Hoodie’s mail feature would work any different from a traditional web app. At some point a server side will validate a client request, and if valid, translate that into sending an email (Gmail comes to mind). Hoodie’s email plugin can do exactly that, except that today’s implementation is a mere sketch of that, like other parts of Hoodie, that show what can be done, but aren’t hardened against production use, yet. None of that means though that Hoodie behaves any differently from a security/abuse/DOS perspective than any other web app :)

Thanks for confirming my crosspost :) However, as I was just saying, wouldn't it be nice to clearly see that we're talking 0.x directly on the website and not only when we install the npm package?

EDIT: Thanks for your answer, I am going to stop crossposting now :D

Our goal is to lower the barrier of entry to build fully capable applications. While using the simple email plugin is not a good idea in a production app, there is no problem to use it with an app that runs on your computer only, or in your companie's intranet.

I know this is nightmare to system architects / backend developers at first sight, but trust us, we know exactly what we are doing. We have excellent architects on our team, you just might not be our primary target group here.

But thanks for your feedback, much appreciated!

To be fair they are still working on 0.x, they probably don't recommend the whole thing to be used in production (although I personally wouldn't mind for some specific projects...). At this stage, I understand they just want to showcase some cool stuff. This being said, we should always be really careful about security when using dependencies, especially when it's in beta, and especially when mostly everything is done client side. It would be also nice if something more explicit was mentioned on the hoodie website. Like the last release version for example (0.x).

Yeah, we are working on a website redesign that addresses this. So much to do, so little time :)

Reply on news.ycombinator.com