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
Comments
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: 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. |
Thanks for reopening this ticket. I was obviously not reading very well what you have written. |
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. |
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.
The text was updated successfully, but these errors were encountered: