Cyberduck Mountain Duck CLI

#7676 closed enhancement (fixed)

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

Reported by: sschlott Owned by: dkocher
Priority: normal Milestone: 4.4.4
Component: openstack Version: 4.4.3
Severity: normal Keywords: Openstack Swift, Temporary URL
Cc: Architecture:
Platform:

Description

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://<Server-DNS-Name>:<Server-Port>/v1/AUTH_* instead of just https<Server-DNS-Name>/v1/AUTH_ (--> <Server-Port> is missing)

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

Change History (10)

comment:1 Changed on Dec 12, 2013 at 6:11:08 PM by dkocher

  • Component changed from core to openstack
  • Milestone set to 4.5
  • Owner set to dkocher
  • Status changed from new to assigned
  • Type changed from defect to enhancement

comment:2 Changed on Dec 13, 2013 at 12:33:07 PM by dkocher

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

In r14150.

comment:3 Changed on Dec 16, 2013 at 9:54:09 AM by sschlott

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.

comment:4 Changed on Dec 16, 2013 at 9:54:59 AM by sschlott

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:5 Changed on Dec 28, 2013 at 9:50:35 PM by dkocher

  • Milestone changed from 4.5 to 4.4.4

comment:6 Changed on Dec 28, 2013 at 10:22:05 PM by dkocher

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

comment:7 Changed on Dec 28, 2013 at 10:23:59 PM by dkocher

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

In r14157.

comment:8 Changed on Jan 6, 2014 at 10:42:04 AM by sschlott

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hi, I just had a luck at your fix (using version r14160) 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.

comment:9 Changed on Jan 6, 2014 at 10:48:44 AM by dkocher

  • Status changed from reopened to new

comment:10 Changed on Jan 6, 2014 at 11:04:18 AM by dkocher

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

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

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