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

URL callback validator is overly strict for non-web clients #28

Closed
trevordevore opened this issue Sep 11, 2014 · 11 comments
Closed

URL callback validator is overly strict for non-web clients #28

trevordevore opened this issue Sep 11, 2014 · 11 comments

Comments

@trevordevore
Copy link

I'm trying to connect a desktop client to a WordPress blog using this library. After making some changes to the check_oauth_signature function I was able to get the URL to open in a web browser so that the user could log in and grant access to my application.

When attempting to redirect the browser reported the error "The callback URL is invalid". In the handle_callback_redirect function the following validation is applied to $callback:

$callback = wp_http_validate_url( $callback );

This validation is problematic for desktop applications. A desktop application has three approaches to using OAuth:

  1. Designate a custom URL protocol that the browser passes off to the desktop application (e.g. myapp://)
  2. Listen on a port of the localhost (e.g. 127.0.0.0:9999)
  3. Perform the whole operation within a browser hosted in the desktop application and intercept the callback URL.

(3) never made sense to me as the user has no way of ensuring that you are indeed sending them to the right website.

I've used (1) and (2) in the past. I use (1) with the OAuth implementations for Dropbox and Evernote.

The issue here is that the OAuth1 code thinks that 127.0.0.1:9999 is an invalid URL. wp_http_validate_url() seems overly strict for the purposes of an OAuth callback URL. I know some services with only allow "http" prefixed URLs or they make you register the callback URL with the service.

@romuloctba
Copy link

+1 on this
Also, 'oob', as described in RFC 5849 section 2.1 doesn't seem to work

@kosso
Copy link
Contributor

kosso commented Oct 30, 2014

+1

@rmccue rmccue mentioned this issue Mar 8, 2015
6 tasks
@yoshito-maeoka
Copy link

+1 too.
For iOS app would be ideal, if we can define a custome protocol. It would be great if we could define by getting consumer key like:

$ wp oauth1 add --custom-protocol=myapp://

then save this protocol, somewhere in wordpress system or somewhere related with the plugin.

@seanfisher
Copy link

+1

@kosso
Copy link
Contributor

kosso commented Jun 13, 2015

We should be able to set oob for an "Out Of Band" callback.

See oauth_callback in section 6.1.1

http://oauth.net/core/1.0a/

(btw: In some native apps I've done, when a provider doesn't support this, I use a fake url that my app knows is wrong, but expects. And as long as the provider doesn't verify that http://my.fake.url/for_my_app doesn't exist, I look for it in the error response and get the token fragments/params that way.)

@itsananderson
Copy link

I like the way GitHub handles this. They register the redirect URL when you register the app. Then they validate that any provided callback URL matches the host and port, and is a subdirectory of the registered redirect URL.

https://developer.github.com/v3/oauth/#redirect-urls

@shankie-codes
Copy link

+1 for a solution here. I'm building a React.js app that consumes data from the API. This issue shouldn't cause any big problems in production, but is a hassle for development as a URL such as http://localhost:9090/callback fails.

It turns out that the main problem for localhost development is that wp_http_validate_url rejects localhost URLs out of hand. To get around this problem, I've written a little plugin (to use in dev environments only) to remove the security restriction. If you needed to, you could probably modify this to allow for certain other conditions to be validate.

How do the developers feel about the API having its own URL validator – such as @itsananderson 's suggestion to emulate GitHub's validator (probably with the addition of an OOB option)?

@rmccue
Copy link
Member

rmccue commented Nov 22, 2015

Sorry for the lack of movement here! This is definitely a problem.

We definitely need a custom validator, and in addition, the ability to store the callback URL for a client so we can match against it. As for the actual validation, we need to make sure the URL scheme, authorization/userinfo, host, port, and path all match. Subdirectories of the registered URL should not be supported right now, as they can open up a lot of potential issues.

FWIW, oob is already supported, and is the method that the CLI client uses to authenticate. I just tested locally, and it works there; if you can't get that to work, please file an issue. (I'm aiming to be more active on this repo, so hopefully we won't have to wait a year to get an issue resolved again. :) )

@kosso
Copy link
Contributor

kosso commented Nov 22, 2015

👍

rmccue added a commit that referenced this issue Nov 23, 2015
rmccue added a commit that referenced this issue Nov 23, 2015
@younes0
Copy link

younes0 commented Nov 23, 2015

thanks @shankiesan

@rmccue
Copy link
Member

rmccue commented Dec 7, 2015

Fixed in #98; please try the latest master out and let me know how it goes, but it should fix all the issues here, including custom protocols. :)

@rmccue rmccue closed this as completed Dec 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants