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

[Vincent Ladeuil]

>>>>> "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.

    jam> If Vincent has gotten the 401 handling correct (which I
    jam> believe he has), 

<cough> RSN ;)

    jam> this would mean we prompt the user for a username and
    jam> password,

So far you have to put the user into the url for a password to be
required (see
https://bugs.launchpad.net/products/bzr/+bug/72792).

    jam> and then continue onwards to connect with a username,
    jam> which now causes us to get the writable server.

    jam> I think that would be very nice and seamless.

    jam> Looking at it more closely, though, it seems that it
    jam> should be done in the SmartWSGIApp itself, rather than
    jam> in a wrapper. It might even need to be done deeper down,
    jam> because the SmartTransport itself is already returning a
    jam> 'ReadOnlyError'.

Or even deeper at the http server configuration ;)

But I'm not against a double handling here.

    jam> Maybe it would be better to have a different
    jam> decorator. Instead of 'readonly+' we would have
    jam> 'writable-requires-auth+'. So it would raise
    jam> 'MustAuthenticate' if a write operation was requested,
    jam> and write_supported was not set.



    jam> Anyway, we have some more layering issues, where the layer that knows
    jam> what is going on isn't the one able to do anything about it.

    jam> Of course, the cheater way to do it is to just have 2 different apps,
    jam> and if environ.get('REMOTE_USER', None) you use the writable one. So
    jam> then if the user uses a url like:

    jam> bzr+http://joe@host.com/

    jam> Then they will be required to authenticate, but if they use:
    jam> bzr+http://host.com/

    jam> Then it would be readonly.

    jam> Thoughts?

*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