Implement Web Portal feature. #389

New Issue

nejucomo · 2008-04-19T22:25:06Z

nejucomo commented

2008-04-19 22:25:06 +00:00

A really simple feature could make Tahoe into a public "web portal". A web portal is a website that presents a given Tahoe directory as it's root url path, for example, these two links would be equivalent:

http://example.website.com/foo/bar.html
http://<my tahoe node>/uri/<web portal dir cap>/foo/bar.html

The portal appears like any other website to surfers (aside from headers and performance). The server can run on a system with a tiny disk, and the web site operator need not worry about site backups.

The security implications seem straightforward, given the design of Tahoe.

I haven't looked at the webish code, but I imagine this could be implemented by adding a single configuration setting for the portal dir cap, and then prefixing all URL requests with "/uri/$dircap" before passing the request to the handler.

A really simple feature could make Tahoe into a public "web portal". A web portal is a website that presents a given Tahoe directory as it's root url path, for example, these two links would be equivalent: `http://example.website.com/foo/bar.html` `http://<my tahoe node>/uri/<web portal dir cap>/foo/bar.html` The portal appears like any other website to surfers (aside from headers and performance). The server can run on a system with a tiny disk, and the web site operator need not worry about site backups. The security implications seem straightforward, given the design of Tahoe. I haven't looked at the webish code, but I imagine this could be implemented by adding a single configuration setting for the portal dir cap, and then prefixing all URL requests with "/uri/$dircap" before passing the request to the handler.

nejucomo added the

labels 2008-04-19 22:25:06 +00:00

nejucomo added this to the eventually milestone 2008-04-19 22:25:06 +00:00

warner commented

2008-04-23 02:10:32 +00:00

(escaped the urls in the description to fix formatting)

warner commented

2008-04-23 02:14:28 +00:00

Hm, so the way that S3 does this is to look for a HTTP/1.1 Hostname: header and manipulate the URL based upon that. In our case, we could have a config file with lines like:

example.website.com: DIRCAP
other.website.com: DIRCAP

and then the twisted.web resource could switch on the Hostname: header to decide what cap to start with.

Security wise, this would give unbounded read- (or write-, if DIRCAP is RW) access to everything below DIRCAP, which is pretty easy to explain and understand.

Intriguing..

Hm, so the way that S3 does this is to look for a HTTP/1.1 Hostname: header and manipulate the URL based upon that. In our case, we could have a config file with lines like: ``` example.website.com: DIRCAP other.website.com: DIRCAP ``` and then the twisted.web resource could switch on the Hostname: header to decide what cap to start with. Security wise, this would give unbounded read- (or write-, if DIRCAP is RW) access to everything below DIRCAP, which is pretty easy to explain and understand. Intriguing..

zooko commented

2008-05-01 12:06:40 +00:00

Couldn't this be implemented by using apache and a reverse proxy?

warner modified the milestone from eventually to undecided

2008-06-01 20:57:45 +00:00

warner added

code-frontend-web

and removed

unknown

labels 2009-03-08 22:03:37 +00:00

zooko commented

2013-09-14 17:37:02 +00:00

nejucomo wrote a reverse proxy config for nginx for this:

https://bitbucket.org/nejucomo/lafs-rpg/

I used it (after tweaking it a bit) for zooko.com:

https://zooko.com/

nejucomo wrote a reverse proxy config for nginx for this: <https://bitbucket.org/nejucomo/lafs-rpg/> I used it (after tweaking it a bit) for zooko.com: <https://zooko.com/>

Sign in to join this conversation.