WebDAV authentication options - google/chromeos-filesystems GitHub Wiki
There are many different systems that the owner of a WebDAV server can use to authenticate users connecting to their server. The authentication UI for the WebDAV provider should handle as many of these as possible.
Username/password
This should be pretty simple. We can have two extra optional fields in the existing configuration UI for the username and password. This should only work for HTTPS servers to avoid sending the password in plaintext.
HTTP Basic auth
I haven't been able to test this but I'm not sure how this works with XMLHTTPRequest. If you navigate to a basic-auth-protected resource in the browser it will pop up a native dialog prompting for credentials, but I'd imagine that XHR requests will just fail with a console error if the client is not authenticated.
OAuth
I don't think there's any feasible way to add OAuth support directly to the provider. An OAuth system has to define a custom callback URL for when the authentication completes, and there's no way for the generic provider to know what that will be for given server. The best idea I have is for companies that use OAuth for authentication and WebDAV as the transport layer to fork and subclass this provider to add their own custom logic.
Cookies
This system works by redirecting the user to a login page if they try to access a protected resource when not logged in. A cookie is then set after logging in, which is used to authenticate future requests. In the experiments I did with this, attempting to load a resource over XHR that uses this authentication method results in successful request, but with the HTML contents of the login page being returned as the data body of the response. We would need a system for
- Detecting which requests have triggered a redirect
- Obtaining the URL to which the request was redirected
- Opening that URL in a popup window to allow the user to authenticate before proceeding with any future requests
Please add others here if you think of them