|Re: Unable to pass credentials through URL to an HTTP Server [message #1211461 is a reply to message #1203455]
||Tue, 26 November 2013 12:52
| Victor Roldan Betancort
Registered: July 2009
I think the primary reason no more was done here was that the resolution on the previous bug (307477) was contributed by Ireneusz Spinalski...and I/we assumed that this was all that was needed.
Thats exactly what I though. Probably they didn't intend to authenticate anything, but rather to have the framework parse that URL syntax properly. Still, makes not much sense to me.
I would therefore be open to other additional contributions here...although I'm curious...what authentication mechanism is going to used the url-encoded password? (Basic auth, or others)? Also...given the url-encoded password is fully in the clear...are p2 repository owners really going to want to expose content via these urls? I guess I had previously assumed that the use case for this was so limited that perhaps it warranted simply creating a new filetransfer provider (based upon httpclient4)...rather than building in this functionality to the existing provider.
I'm not an expert in HTTP authentication, but:
a) In our case, basic auth would go through HTTPS
b) No, its not ideal to have credentials in the P2 URL, but Bucky currently does not provide any other means to inject credentials. This feature is just missing, and surprising nobody ever asked about it.
I believe that also, somewhere in the call stack, P2 queries the Equinox Secure Storage for credentials, and that could help avoiding credentials in plain-text, but is not clear to be whats going on there. Maybe I should ask in the P2 forum.
If you still think this URL-encoded auth feature is welcome, I shall open a 'zilla.
Thanks for your support!
Víctor Roldán [Open Canarias]
Powered by FUDForum
. Page generated in 0.21964 seconds