[RFC] Authentication and supporting Push through bzr+http://

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:
>>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:
> 
>     jam> I've been trying to think about how to expose both a
>     jam> readonly and write-if-authenticated smart server support
>     jam> for the bzr+http:// protocol. I have a general idea that
>     jam> I wanted to discuss, though I'm not sure how to actually
>     jam> implement it yet.
> 
>     jam> Basically, you would configure 2 SmartWSGIApps, one
>     jam> using a readonly transport, and one with a normal
>     jam> transport. (By the way, one of the *really* *really*
>     jam> weird things about this layering is that you could
>     jam> actually expose a connection to a 3rd party machine
>     jam> using bzr+ssh or sftp as the back end :)
> 
>     jam> Anyway, you would check if the user had been
>     jam> authenticated, and if they had, you would call
>     jam> writable_wsgi_server.run(req) versus
>     jam> readonly_wsgi_server.run(req).
> 
> I think that should be doubled on the http side by adding:
> 
> 	<LimitExcept GET HEAD OPTIONS>
> 		Require valid-user
> 	</LimitExcept>
> 
> inside the appropriate Directory directive.
> 
>     jam> The real trick is that if you get a
>     jam> TransportNotPossible, you could translate it into a HTTP
>     jam> 401 "Unauthorized" response.
> 
> The modification above will trigger 401 for all requests except
> GET, HEAD or OPTIONS.


All smart server requests are POST requests. If you want to have
readonly be a dumb http transfer, you can already do that by just
requiring authentication for .bzr/smart.

...

> 
> *Iff* the smart server protocol use POST for write operations and
>  GET/HEAD for read operations, the proposed configuration
>  modification could be enough. But I'm not sure the separation is
>  clean today nor that it will stay that way.
> 
>        Vincent
> 

It isn't really reasonable to use GET for read operations, since you
will be sending a lot of data up. Like the future query to pass parts of
the local revision history, so that you can get a return value of what
is different in the remote revision history.

Some of the readonly requests are going to be passing several KB (10,
100?, 1M?) So I don't think that is well handled by GET.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFi9ysJdeBCYSNAAMRAhTpAKCfJreniREl4dCQBIoTFenFL+Gh+QCfQ5BW
nfkRCK+ryXLzt0/mDuCJgek=
=EI0g
-----END PGP SIGNATURE-----