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

Cloud Files authentication re-use #2876

Closed
cyberduck opened this issue Jan 11, 2009 · 5 comments
Closed

Cloud Files authentication re-use #2876

cyberduck opened this issue Jan 11, 2009 · 5 comments
Assignees
Labels
Milestone

Comments

@cyberduck
Copy link
Collaborator

93e4b56 created the issue

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [2876 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?

@cyberduck
Copy link
Collaborator Author

93e4b56 commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 142bd1c and c0f8543.

@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.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants