Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Would you trust such a system if it was built into the web framework you were using, such that the closure signing/serialization/etc. code was thoroughly tested in many environments (e.g. Seaside)?

Or, actually, is it just the signature-checking code you're worried about writing? nginx (among many other reverse proxies) has a battle-tested signed-URL parsing module[1] available as part of its authentication-time processing. In such a setup, you tell nginx which routes need signature protection, and then nginx will only proxy_pass requests on those routes to your app when the signature is valid, stripping the signature off in the process (so they become regular unsigned requests as far as your app is concerned—with the fact that they made it to your app at all telling you they were signed.)

With that architecture, the only code you'll write is the code to generate signed links that comply with ngnix's expectations (which there might already be a library to do in your language.) Either way, if you screw that part up, you'll just have a bunch of invalid links, not a security hole.

[1] http://nginx.org/en/docs/http/ngx_http_secure_link_module.ht...



Yes, if my involevment was limited to just creating a closure and passing it to the library that is secure, vetted and tested, then sure. With project like HN, I think all of this would be written from scratch, but if e.g. Django had this feature built in, I would be much more comfortable with it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: