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

Openstack Swift Temporary URL Links should contain HTTP Port (as well) #7676

Closed
cyberduck opened this issue Dec 12, 2013 · 6 comments
Closed
Assignees
Labels
enhancement fixed openstack OpenStack Swift Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

d1afbb2 created the issue

If using Cyberduck with a "Temporary URL" enabled Openstack Swift Account, a right-click on a file presents 3 different temporary URLs under 'Copy URL'.

The Temp URLs should contain the HTTP/S Port of the serving Swift Server as it may not be the standard port 443 for HTTPS. The presented URL 'HTTPS URL' presents the URL with the server port, but the temp URLs do not.

example:

it should be https://:/v1/AUTH_***
instead of just https///v1/AUTH_**** (--> is missing)

The right Swift Base URL is given by the used Keystone Endpoint and the according catalog entry.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 18f0f7e.

@cyberduck
Copy link
Collaborator Author

d1afbb2 commented

Hi, I had just had a look at the snapshot build 14153, which should contains the changes mentioned above, I guess.

It seems as if there was a slight misunderstanding regarding what was meant with showing the right port. The intention was not to show the same links for HTTP as well as HTTPS. At our deployment Swift listens with HTTPS but not at 443. The intention was to recognize the non-standard port (e.g. 8080 or 8888) as given in the Openstack Keystone catalog.

I try to make the underlying problem more clear:
An Openstack deployer might want to provide different services (e.g. API endpoints) listening on different ports at the very same IP address. A deployment might look like this:

keystone.deployment.de (DNS A Record --> IP1)

object.deployment.de (DNS A Record --> IP1) --> Openstack Swift

with the following service endpoints:

https://keystone.deployment.de:5000/v2.0

https://object.deployment.de:8080/v1/AUTH_

E.g. we have one deployment where the Swift Endpoint is reachable through port 8080 but with HTTPS. In the context menu 'Copy URL' the 'HTTPS URL' is right - it shows https://DNS-NAME:8080/v1. The links for the Temporary URL should also contain port 8080 and HTTPS, because that is the location where Swift listens and which is correctly provided by the Keystone service catalog.

The reason for the ticket was that the Temporary URLs did not point to the Swift endpoint correctly (because of the missing port). Also, the port could be 1234, 8888 or every other valid port not already used. It just has to match the content of the Keystone service catalog entry describing Swift's public URL of this deployment.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Thanks for reopening this ticket. I was obviously not reading very well what you have written.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 7b7b151.

@cyberduck
Copy link
Collaborator Author

d1afbb2 commented

Hi, I just had a luck at your fix (using version 53993a5) and it works fine - thanks for that. The only thing ist that the http URLs are still provided as links as well. The problem is that some swift are not listening as plain http. We could solve this be redirecting everything from http to https on the server-side, but I think it would be more clean, if Cyberduck would always use the Keystone entry for publicURL as the basis. If the deployer defines http in Keystone, then Cyberduck should provide the link with http and whatever port, if a https URL is given for deployment, then this should be used. The Openstack Keystone endpoint catalog is designed for exactly that flexibility.

Thanks for all your effort and the great tool Cyberduck. It is great how you provide an easy interface to more advanced Swift features, for example. It would be perfect if it would also run on Linux, the system I normally use ;)

Regarding the still (very little!!!) problem: I think that still provided wrong URLs are just a remnant of the intermediate HTTP version.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In deafd67. Only take scheme into account that is advertised in the storage URL of the region.

@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
enhancement fixed openstack OpenStack Swift Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants