-
Notifications
You must be signed in to change notification settings - Fork 112
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
Comments
+1 on this |
+1 |
+1 too.
then save this protocol, somewhere in wordpress system or somewhere related with the plugin. |
+1 |
We should be able to set See oauth_callback in section 6.1.1 (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.) |
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. |
+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 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)? |
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, |
👍 |
thanks @shankiesan |
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. :) |
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:
This validation is problematic for desktop applications. A desktop application has three approaches to using OAuth:
(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.
The text was updated successfully, but these errors were encountered: