Hey, thanks for getting back.

1) Ok, so maybe we could push this change there? To be seen.

2) You are storing a plaintext password on a local file, this is what I say should be avoided. But then you can also say that I might store a token in a file (although they are short lived and limited in scope). But fine, it's not much better...

3) you usually have an access token and a refresh token. The access is the one that is used and should be valid for some minutes. You use the refresh to.. refresh and get 2 new tokens. This last token can be requested to have a longer time (it's called offline access), but even then it should have an expiration time.

4) What I was saying is that, just like the user/pass combo, maybe we can assume that they exist and got created by someone. In our case, we already have an application that refreshes and stores the valid token in a file. To send it, as it was mentioned, we just need to set the header with the token we got.

5) Ofc we could do the refresh from davfs, but as in point 4) we can assume it's being updated outside of davfs. This first iteration would make the implementation in davfs simple and still allow these integrations by delegating that task.

And I'm not seeing any problem. I already have an app that gets tokens updated and stores them in files. I mentioned before that there are many libraries that can be used to read the token and see its expiration (you can decode it). If you know the expiration, you know when this token is invalid, therefore you do not need to read the file every-time you do a request.. Only when it's invalid.

Ofc the token might've been revoked, or maybe you read the file again and you realize that it's still expired. But so can a password be revoked... I don't see why wouldn't davfs behave exactly the same in both cases.

If you want, I can explain our use case in more detail. We might even find someone willing to contribute this change to the code (we're loooking). But I would prefer to know beforehand wether you're going to be against it by principle or open to the proposal.

Cheers,
Diogo

Hi,

As Alexey mentioned, oAuth is the way every cloud provider is moving precisely because it allows the use of different tokens for different services, they have shorter life than a password (so stealing them is not usually a major problem), you can do delegation, etc, etc. Some have removed the basic auth altogether and many others are considering the same (having plain text passwords is something that nobody should do in this day and age).

While the protocol might be harder to implement and there might be other considerations about it, I don't see what that has to do with this dav client... These problems are for the services that need to implement the authentication flow. This webdav client doesn't do authentication, it just needs to send the standard authorization header with the token that it got from "someone/somewhere" (and there is no "implementation for different commercial services", they need to accept "Authorization: Bearer xxx").

The only problem, since tokens might be short(ish) lived, is that we might need to update them. Again, this webdav client doesn't need to do anything special. One possibility is that it just fails. But I would suggest it  tried to read the secrets file once more, as it might have been updated already with a newer one, and doing the call again before failing. An optimization would be to read the token to check its expiration to avoid a round trip (there are a couple of libraries that can be used: https://jwt.io/).

Do you think this could be done?
Diogo

>  I already did - a long time ago. With option "add_header" you can add any header you want, e.g. your non-standard authorization header. Details are in "man davfs2.conf".

Thanks for info, this is exactly that I want for customize connection auth string! Before I search this in secrets file documentation only.

I try this, and if I fill 'add_header' option, davfs2 seems still add "Basic" header line (even with empty secrets file and ask_auth=0) when talking with webdav server, so connection to Yandex fails with error:

mount.davfs[2970]: davfs2 1.5.5
 mount.davfs[2970]: Initializing webdav
 mount.davfs[2970]: ah_create, for WWW-Authenticate
 mount.davfs[2970]: ah_post_send (#0), code is 401 (want 401), WWW-Authenticate is Basic realm="Yandex.Disk"
 mount.davfs[2970]: auth: Got challenge (code 401).
 mount.davfs[2970]: auth: Got 'Basic' challenge.
 mount.davfs[2970]: auth: Trying Basic challenge...
 mount.davfs[2970]: auth: Accepted Basic challenge.
 mount.davfs[2970]: auth: Sending 'Basic' response.
 mount.davfs[2970]: ah_post_send (#1), code is 401 (want 401), WWW-Authenticate is Basic realm="Yandex.Disk"
 mount.davfs[2970]: auth: Got challenge (code 401).
 mount.davfs[2970]: auth: Got 'Basic' challenge.
 mount.davfs[2970]: auth: Trying Basic challenge...
 mount.davfs[2970]: authentication failure:
 mount.davfs[2970]:   Yandex.Disk
 mount.davfs[2970]: auth: No challenges accepted.
Could not authenticate to server: rejected Basic challenge

How can I configure davfs2 to not send Basic auth header, and use only strings from 'add_header'?

Also in davfs2.conf I can set only global value for all hosts, not per-host, like in ~/.davfs2/secrets file.

So can you please add similar feature to ~/.davfs2/secrets file? Thanks!


P.S. I have found description of Yandex WebDAV connection in English here: https://tech.yandex.com/disk/webdav/

> Your provider allows different OAuth-tokens for different services but does not allow different passwords for different services. That is voluntary nonsense. You should ask your provider to change this and just comply to the standards.

Can you ask Google to provide different passwords for each service in your personal account? One password for GMail, second for Google Docs, third for Google Calendar, etc? No, google suggest use personal tokens for each service to, like most of other providers!

So now davfs2 allow to use only hard-coded format of Authorization header string:
"Authorization: Basic [base64(login:password)]"

I ask to add any way for override this hard-coded format via custom string, filled in ~/.davfs2/secrets file.

I don't speak russian and I have no idea how you get that frequently changing token. More generally:

From RFC 6749:
"The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, ..."

It has nothing to do with how the owner(s) of the resource access the resource. I can't see why this token would be in any way more secure than a password. By the way: for almost a quarter of a century it is common practice to use a SSL/TLS-connection when transfering credentials.

Additionally: OAuth comes in two RFC's (6749 and 6750) with 75 and  17 pages. Wikipedia writes (https://en.wikipedia.org/wiki/OAuth#Controversy):
"Eran Hammer resigned from his role of lead author for the OAuth 2.0 project, ...
...
In comparing OAuth 2.0 with OAuth 1.0, Hammer points out that it has become 'more complex, less interoperable, less useful, more incomplete, and most importantly, less secure.'"

And finally it is highly extensible and you probably would have to write different code for every comercial server. I will not engage in this.

Werner

Many WebDAV cloud providers disabling default basic plain text auth by security reasons, and use tokens for authorization.

For example, here https://yandex.ru/dev/disk/doc/dg/concepts/quickstart-docpage/ is described Yandex OAuth token authorization method (in Russian). With basic auth Yandex.Disk WebDAV works very bad because of manual traffic limits and forced connection drops on server side :(

Seems davfs2 now support only Basic Auth, described ad https://tools.ietf.org/html/rfc2617 - yes?

Can you please add custom token authorization method to davfs2?

Seems this is not so hard, we only need to change "Authorization" header line from:
"Authorization: Basic [base64(login:password)]"
to
"Authorization: OAuth [token string]"

In ~/.davfs2/secrets file this can be represented as:
https://webdav.example/path "[full authorization header line text]"

Example:
https://webdav.yandex.ru/ "OAuth 0c4181a7c2cf4521964a72ff57a34a07"

What do you think about this idea? Thanks!