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

Invalid default port used for X-Storage-Url if authentication URI has non default port #6570

Closed
cyberduck opened this issue Mar 2, 2012 · 13 comments
Assignees
Labels
bug fixed openstack OpenStack Swift Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

e68e255 created the issue

Use-case involving Openstack Swift and Keystone:

If the X-Storage-Url has an endpoint (https) without specifying the port number (443), Cyberduck will default to using the Keystone's port instead of the 443 default port for https X-Storage-Url endpoint. Per rfc2818, we should default to 443 if an https port is not specified.


Attachments

@cyberduck
Copy link
Collaborator Author

@dkocher commented

I cannot find this bug looking into the code. Can you verify

  • This is still an issue with the latest snapshot build.
  • Or you have a public instance I can connect to to reproduce the issue.

@cyberduck
Copy link
Collaborator Author

e68e255 commented

I tried it with the latest snapshot build (9485) version 4.2.1 with same results. Steps to reproduce:

  • Install Swift (running on HTTPS, port 443)
  • Install Keystone, be sure to set the Swift endpoint to point to your Swift instance with HTTPS protocol and do not specify the port number, so the URL should be something like https://<swift_proxy>/v1.0/%tenant_id%.
  • Point Cyberduck to authenticate with your Keystone instance via port 35357 (using the Cyberduck's Swift connector)
  • Capture the HTTP traffic with a proxy like Burp or Paros so you can see the requests and responses.
  • You will see that Keystone responses the authentication request with an X-Storage-Url: https://<swift_proxy>/v1.0/<tenant_id>
  • Cyberduck then makes a GET to Swift proxy on port 35357! (should be using 443)
  • At this point, if you modify the request to use port 443, then the Swift GET will succeed, else it will fail.

It appears that Cyberduck tries to use the port of the auth host, despite the fact that X-Storage-Url specifies https or even port 443.

Please let me know if you need help reproducing this.... Thanks.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Because the scheme registry has the default port set for the protocol from the authentication URI, we then use this port as the default port if not port is specified in the storage URI. We will have to fix this in Cloudfiles.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In this commit and possibly fixed here with 0503152.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Pushing a new snapshot build just now for testing.

@cyberduck
Copy link
Collaborator Author

e68e255 commented

Thanks, dkocher! Can you let me know when the snapshot build is ready? I will help verify it. I just did a snapshot build check from Cyberduck, but don't see anything new yet (still on 9485).

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:7 liemmn]:

Thanks, dkocher! Can you let me know when the snapshot build is ready? I will help verify it. I just did a snapshot build check from Cyberduck, but don't see anything new yet (still on 9485).

Build 9487 is now available.

@cyberduck
Copy link
Collaborator Author

e68e255 commented

Doing a snapshot update from Cyberduck (Windows) still yields 9485. I tried reinstalling Cyberduck to no avail... Any ideas? Thanks.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:9 liemmn]:

Doing a snapshot update from Cyberduck (Windows) still yields 9485. I tried reinstalling Cyberduck to no avail... Any ideas? Thanks.

A new snapshot build for Windows is now available as well.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Let me know if this fix works for you as I didn't test this myself.

@cyberduck
Copy link
Collaborator Author

e68e255 commented

I updated to build 9488. I got the following NPE before a connection was made to Keystone:

2012-03-24 13:19:38,181 [Thread-0] DEBUG ch.cyberduck.core.Host - setProtocol:swift
2012-03-24 13:19:38,182 [Thread-0] DEBUG ch.cyberduck.core.Host - setHostname:csnode.rndd.aw1.hpcloud.net
2012-03-24 13:19:38,182 [Thread-0] DEBUG ch.cyberduck.core.Host - setEncoding:null
2012-03-24 13:19:38,185 [Thread-0] DEBUG ch.cyberduck.ui.AbstractController - background:csnode.rndd.aw1.hpcloud.net
2012-03-24 13:19:38,187 [Thread-0] INFO  ch.cyberduck.ui.AbstractController - Scheduled background runnable csnode.rndd.aw1.hpcloud.net for execution
2012-03-24 13:19:38,187 [background-9] DEBUG ch.cyberduck.ui.AbstractController - Acquired lock for background runnable:csnode.rndd.aw1.hpcloud.net
2012-03-24 13:19:38,190 [background-9] INFO  ch.cyberduck.core.Session - Mounting csnode.rndd.aw1.hpcloud.net
2012-03-24 13:19:38,193 [background-9] DEBUG ch.cyberduck.core.ssl.CustomTrustSSLProtocolSocketFactory - Using SSL context:javax.net.ssl.SSLContext@14d24a
2012-03-24 13:19:38,264 [background-9] ERROR ch.cyberduck.ui.AbstractController - Exception running background task:null
java.lang.NullPointerException
	at java.net.URI$Parser.parse(URI.java:3019)
	at java.net.URI.<init>(URI.java:595)
	at java.net.URI.create(URI.java:857)
	at com.rackspacecloud.client.cloudfiles.FilesClient.parseURI(FilesClient.java:332)
	at com.rackspacecloud.client.cloudfiles.FilesClient.<init>(FilesClient.java:152)
	at ch.cyberduck.core.cf.CFSession.connect(CFSession.java:102)
	at ch.cyberduck.core.Session.check(Session.java:98)
	at ch.cyberduck.core.Session.mount(Session.java:280)
	at ch.cyberduck.core.Session.mount(Session.java:269)
	at cli.Ch.Cyberduck.Ui.Controller.BrowserController$MountAction.run(Unknown Source)
	at ch.cyberduck.core.threading.AbstractBackgroundAction.call(AbstractBackgroundAction.java:94)
	at ch.cyberduck.ui.AbstractController$1.call(AbstractController.java:94)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:167)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:604)
	at java.lang.Thread.run(Thread.java:883)
	at cli.System.Threading.ThreadHelper.ThreadStart_Context(Unknown Source)
	at cli.System.Threading.ExecutionContext.runTryCode(Unknown Source)
	at cli.System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(Unknown Source)
2012-03-24 13:19:38,275 [Thread-0] DEBUG ch.cyberduck.core.Session - connectionDidClose
2012-03-24 13:19:38,275 [background-9] DEBUG ch.cyberduck.ui.AbstractController - Releasing lock for background runnable:csnode.rndd.aw1.hpcloud.net

The auth host in this case is csnode.rndd.aw1.hpcloud.net running on port 35357.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Let me know if 2a8f3da works.

@cyberduck
Copy link
Collaborator Author

e68e255 commented

It works! Woohoo!

Thanks, again, Dave.

Liem

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

No branches or pull requests

2 participants