Cyberduck Mountain Duck CLI

#7163 closed enhancement (wontfix)

Support of authentication cookies

Reported by: elgo Owned by: dkocher
Priority: low Milestone: 4.3
Component: webdav Version: 4.2.1
Severity: minor Keywords:
Cc: Architecture:
Platform:

Description

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.

Change History (6)

comment:1 Changed on Apr 15, 2013 at 9:58:30 AM by dkocher

  • Milestone set to 4.3
  • Status changed from new to assigned

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

comment:2 Changed on Apr 15, 2013 at 10:55:16 AM by dkocher

  • Resolution set to worksforme
  • Status changed from assigned to closed

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

comment:3 Changed on Apr 16, 2013 at 12:37:49 PM by elgo

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

comment:4 Changed on Apr 16, 2013 at 12:38:43 PM by elgo

  • Priority changed from normal to low
  • Resolution worksforme deleted
  • Severity changed from critical to minor
  • Status changed from closed to reopened

comment:5 Changed on Apr 16, 2013 at 2:09:24 PM by dkocher

  • Resolution set to wontfix
  • Status changed from reopened to closed

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.

comment:6 Changed on Apr 16, 2013 at 2:10:18 PM by dkocher

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.

Note: See TracTickets for help on using tickets.
swiss made software