Require authentication for the web interface about zkapauthorizer HOT 7 CLOSED

Could _VoucherCollection merely inherit from allmydata.web.common.TokenOnlyWebApi ...? (The latter would have to be upgraded to allow PUT as well as the current POST)

from zkapauthorizer.

Oh, hrmmm ... I see _VoucherCollection also includes render_GET. The tokens are not allowed as query-style arguments currently, based on warner's argument that "URIs tend to leak" and we should never put the token itself into "not a request body". PUT can have a request body, though, correct?

from zkapauthorizer.

ahh, but the PUT for that as currently specified contains only a JSON body. So, maybe literally subclassing that is indeed a bad idea ... but something will have to change anyway to get the tokens to the server (and I agree with warner that putting them in the URL is probably a bad idea .. so maybe "get the list of all vouchers" can't / shouldn't be a GET)...

from zkapauthorizer.

Maybe this is the reason HTTP has the Authorization header and is more reason to nudge Tahoe-LAFS in that directory? Authorization is compatible with GET and also doesn't leak the information into a URL.

Twisted Web also has first-class support for Authorization header-based authorization (in twisted.web.guard).

from zkapauthorizer.

(though twisted.web.guard isn't always trivial to use so it might be better to hack something in to one of the existing parent resources instead :/ and then follow-up with a more maintainable implementation later.)

from zkapauthorizer.

Ah, yeah Authorization: <token> sounds like a better solution all-around -- especially since it would support any HTTP-verbs we want and not put weird requirements on the body of those requests. (now that it has been said, I don't know why it didn't come up before ;).

The existing "token" stuff in Tahoe's Web-API was regarded as a "trial" for how to do a complete "version 2" API .. by which I mean, I don't think it would be at all controversial to switch to that. It's not a "public" API, and the only thing using it is the "tahoe status" CLI piece.

Not sure how keen I'd personally be on t.w.guard, mostly based on long-ago memories of it "being hard" ... but also maybe a fresh look would change my mind ;)

from zkapauthorizer.

Looking in Tahoe code again/some more there's already a /private hierarchy which uses Authorization: tahoe-lafs <token> which makes everything under /private only accessible if you pass the web-api token in...

from zkapauthorizer.