Cyberduck Mountain Duck CLI

Opened 9 years ago

Closed 9 years ago

#2876 closed enhancement (fixed)

Cloud Files authentication re-use

Reported by: ej@… Owned by: dkocher
Priority: normal Milestone: 3.2
Component: cloudfiles Version: 3.1.1
Severity: normal Keywords: cloudfiles optimization
Cc: Architecture:
Platform:

Description

Optimization tip: When the Log Drawer is open, I can see the HTTP request/response headers (thanks for that!). What I've noticed is that unnecessary authentication calls are being repeated. This may be an artifact of the application's internals and multiple connections, but Cyberduck only needs to authenticate once. The X-Auth-Token returned by a successful authentication can be used for each connection to the storage or CDN systems. Also, the URLs to the storage and CDN systems do not change between requests, so that information can be cached and re-used between each connection.

So what I expected to see in the Log Drawer was one connection to https://api.mosso.com/auth with appropriate headers. The response's X-Auth-Token, X-Storage-Url, and X-CDN-Management-Url can be cached and re-used for each subsequent connection.

Be warned that the token will expire over time (possibly as short as an hour). The application should trap a 401 (Unauthorized) response on a given request (to either storage or cdn system) and then re-authenticate to obtain an updated token.

If you have any follow-up questions/comments, feel free to stop by freenode.net #cloudfiles. We're not always "alive", but we'll answer when we wake up.

Change History (7)

comment:1 Changed 9 years ago by dkocher

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

comment:2 Changed 9 years ago by dkocher

Currently we pro-actively authenticate because the Mosso API does not consistently wrap the 401 responses into a FilesAuthorizationException` (only some methods). Will have to fix this first.

comment:3 in reply to: ↑ description Changed 9 years ago by dkocher

Replying to ej@…:

Be warned that the token will expire over time (possibly as short as an hour). The application should trap a 401 (Unauthorized) response on a given request (to either storage or cdn system) and then re-authenticate to obtain an updated token.

Is the token expiry date updated upon subsequent requests? Or does it expire for sure even if a successful request is made with the same token at 00:59?

comment:4 Changed 9 years ago by ej@…

It currently generates a new token each hour. I consider this sub-optimal and should re-send the same token under periodic use for a longer period.

comment:5 Changed 9 years ago by dkocher

  • Milestone changed from 3.1.2 to 3.2

comment:6 Changed 9 years ago by dkocher

  • Milestone changed from 3.2 to 3.1.3

Skimming the diff of the updated official API implementation available 1.3, there are now re-logins made for SC_UNAUTHORIZED responses. We should merge this into our trunk.

comment:7 Changed 9 years ago by dkocher

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

In r4507 and r4510.

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