Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support of authentication cookies #7163

Closed
cyberduck opened this issue Apr 15, 2013 · 5 comments
Closed

Support of authentication cookies #7163

cyberduck opened this issue Apr 15, 2013 · 5 comments
Assignees
@dkocher
Labels
enhancement low priority webdav WebDAV Protocol Implementation wontfix
Milestone
4.3

Comments

@cyberduck
Copy link
Collaborator

56317c3 created the issue

Hi,

I'm hitting some no-go in the painful way of getting up an interesting setup: I want to secure access to a webdav using token/One Time Passwords.
The server side is already "working" (apache/mod_dav/mod_radius/freeradius & token backend).
But in general, webdav clients (that aren't internet browsers. IE is fine for example) and cyberduck especially cache login/pwd and reuse them each request they do... Problem is they won't use the authentication cookie that may be (and is in my setup) set by the dav server.
So the client keep asking for a password each time it does a request (because OTP is only valid once... of course).

So, is there a chance to see this feature "cookie support" in cyberduck any time? (soon, of course ;)).
That would be a great deal for cyberduck, because there is no opensource fullfeatured webdav client supporting cookies so far, only the python dav libs do.
Oh, and neither win7 or macOSX native webdav clients (didn't test kde one) support them either, so there is a spot.
@cyberduck
Copy link
Collaborator Author

@dkocher commented

Can you post the transcript from the log drawer (⌘-L) that shows that the Cookie header is not set using the snapshot build available.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Explicit cookie policy in e7f80d3. However, this was already the default before.

@cyberduck
Copy link
Collaborator Author

56317c3 commented

Ok, I gathered some more data, and I can confirm than "it works" out of the box I connect directly into the directory protected (/secure).

But I I first connect to the parent unprotected directory (/), then going into the protected directory fails. It seems to replicate the problem encoutered with usual browsers that "use" the credentials (so the OTP) on prefetching some files (like index.* or favicon. Cyberduck looks for a favicon too) but doesn't retain the cookie they got at these steps. Then OTP is not valid anymore.
See: http://freeradius.org/mod_auth_radius/README at "Some warnings".

Logs:

HEAD / HTTP/1.1
Host: 10.163.4.168
Connection: Keep-Alive
User-Agent: Cyberduck/4.3 (Mac OS X/10.6.8) (i386)
Authorization: Basic ZmxvcmVudC5kdXRoZWlsOkhBaTFjaGlvdDRjZXRkdm5sbmhodmt2ZHVpcmVqamd0dmNmdHZoZW5ldmVsbHVyZnRqbmZkaw==
HTTP/1.1 200 OK
Date: Tue, 16 Apr 2013 12:34:13 GMT
Server: Apache/2.2.14 (Ubuntu)
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=UTF-8
PROPFIND / HTTP/1.1
Depth: 1
Content-Type: text/xml; charset=utf-8
Content-Length: 99
Host: 10.163.4.168
Connection: Keep-Alive
User-Agent: Cyberduck/4.3 (Mac OS X/10.6.8) (i386)
Authorization: Basic ZmxvcmVudC5kdXRoZWlsOkhBaTFjaGlvdDRjZXRkdm5sbmhodmt2ZHVpcmVqamd0dmNmdHZoZW5ldmVsbHVyZnRqbmZkaw==
HTTP/1.1 207 Multi-Status
Date: Tue, 16 Apr 2013 12:34:14 GMT
Server: Apache/2.2.14 (Ubuntu)
Content-Length: 2652
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/xml; charset="utf-8"
PROPFIND /secure/ HTTP/1.1
Depth: 1
Content-Type: text/xml; charset=utf-8
Content-Length: 99
Host: 10.163.4.168
Connection: Keep-Alive
User-Agent: Cyberduck/4.3 (Mac OS X/10.6.8) (i386)
Authorization: Basic ZmxvcmVudC5kdXRoZWlsOkhBaTFjaGlvdDRjZXRkdm5sbmhodmt2ZHVpcmVqamd0dmNmdHZoZW5ldmVsbHVyZnRqbmZkaw==
HTTP/1.1 401 Authorization Required
Date: Tue, 16 Apr 2013 12:34:18 GMT
Server: Apache/2.2.14 (Ubuntu)
WWW-Authenticate: Basic realm="RADIUS authentication for localhost"
Content-Length: 479
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

@cyberduck
Copy link
Collaborator Author

@dkocher commented

We changed the authentication handling because of #7139 and will not prompt for credentials upon failures opening folders once we have authenticated against the default path in the bookmark when connecting. As a workaround, set the Default Path to /secure in the bookmark.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please open another issue if you want this to be changed and/or add a comment to #7139. The original issue reported (Authentication cookies) has been closed with status worksforme.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@dkocher dkocher

Labels
enhancement low priority webdav WebDAV Protocol Implementation wontfix
Projects
None yet
Milestone
4.3
Development

No branches or pull requests
2 participants
@dkocher @cyberduck