Hello tahoe-dev, There is demand for a more "locked down" webapi that the public can use to retrieve content from a Tahoe-LAFS network, while minimizing risk to the webapi operator. I too have wanted this for awhile, and I've implemented a set of HTTP redirection and access control rules in haproxy.
I've made a script to stick the right parameters in the right spots of the configuration and bundled it up here: https://bitbucket.org/nejucomo/lafs-rpg/overview This repository is intended to allow you to get a "public gateway" to Tahoe content up and running on a debian system with minimal fuss. Let me know if you try it and something doesn't work. (Also, I've tried to document it well, let me know if that needs improvement.) I've spent some time thinking about and researching the webapi frontend to understand what "locked down" should be. If you want a public webapi that is read-only, this project is a good start and *should be* reasonably secure. However, security is much harder to notice than a lack of security. If you see flaws, please let me know with the bitbucket issue tracker. I've created some new Tahoe-LAFS tickets and rounded up old tickets that seem relevant to this project: Here's a "brainstorm" that urges the community to think about the case where an operator wants to provide a public gateway but have some safeguards against malicious users: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1665 That links to other tickets about documenting the webapi URL structure (#1663) in a concise way (to make access policies easier to reason about), and a few old ones about unconstrained uploads (#587) and leaking an introducer furl (#860). I've just set up a lafs-rpg site, with not much in the way of content, in case you want to poke at a live demo: https://con.struc.tv Regards, Nathan _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
