OAuth callback rejected on new developer site (works on apps.twitter.com)

[MagicalTux]

With the switch to the new site we are required to fill “Tell us how this app will be used” for each app, however submitting some text there won’t work properly as upon clicking “Save”, the screen scrolls up and “Invalid website url” appears under the oauth callback url (set to https://my.atonline.com/_special/rest/OAuth2/Consumer:return).

It used to work just fine before, and the configured apps are still working fine. I’m guessing the new site rejects the url probably because of the “:” inside it, but “:” shouldn’t be particularly problematic in uri paths (allowed as per rfc3986)

[LeBraat]

Hello @MagicalTux

Thanks for writing in. I’m going to have to check with our team on this one. I’ll get back to you on this.

[LeBraat]

We are having internal discussions around this subject. More to come.

[MagicalTux]

Thanks. Let me know if there is anything I can do to help, or if you need any other kind of information.

[LeBraat]

I will make sure to update you as I receive material information from our product team.

[chrisdeeming]

@LeBraat we have thousands of customers who, to make use of very simple functionality such as “Sign in with Twitter” will need to (now) be sent to https://developer.twitter.com/ to register and create apps.

These people are mostly not developers and not technical, though with well written instructions, they may just be able to do it.

Frankly, though, I think the process for registering on the new portal is hugely convoluted and asks too many questions which are just irrelevant to a normal administrator of our software. Further, the functionality provided is of no interest to them. I think moving the apps stuff to a very developer focused area is a huge mistake.

Anyway; now that is off my chest, back to the original topic.

There are further changes you have made here for the callback URL validation which are illogical and have broken the ability to edit older apps.

First, it is no longer possible to set a callback URL which points to http://localhost. How do you expect developers to be able to quickly and easily test their implementations if they are only testing locally? What’s the point in this arbitrary restriction when all I’d need to do is add a local hosts entry to a FQDN? Or just use http://127.0.0.1? It looks like the validation is attempting to force a FQDN here so although you could just whitelist localhost that wouldn’t solve the problem for users who may be wanting to use http://dev or similar.

Second, it is no longer possible to use query strings in callback URLs. Although our customers can enable “friendly” URLs, by default a customer URL would be something along the lines of http://example.com/index.php and they would need to redirect to the actual application logic for Twitter which would be http://example.com/index.php?register/twitter in older versions of the software. In newer versions of the software, whether friendly URLs are enabled or not, the callback URL for a “Sign in with Twitter” requeast would be http://example.com/connected_account.php?_xfProvider=twitter. In older versions of the software we have a test suite for signing up with Twitter (and others) and this requires access to a URL similar to http://example.com/admin.php?tools/test-twitter.

Put simply, the current approach completely breaks some existing apps for development purposes with valid use cases. And worse, the current approach will prevent all of our customers ever being able to set up “Sign in with Twitter” at all. These changes seem very arbitrary and counter intuitive, so I look forward to changes being made here.

Twitter is currently the only platform which is adding such unnecessary and stringent URL validation.

[MagicalTux]

Also a side note: because this is considered invalid, it prevents inputting “Tell us how this app will be used” and migration of the account from the old to new system seems to require this:

To help us understand how you use your existing apps, please edit each of your apps and add a description of your app’s use case where it says “Tell us how this app will be used”.

Description can’t be saved because the url is “invalid”, but “fixing” the url means breaking production login flows just to hopefully have the account eventually verified. I am unable to create needed new apps because of this, so some kind of timely resolution of this specific issue would be appreciated.

• on the “old” twitter apps website, inputting this kind of callback url was accepted and never caused any issue
• on all other OAuth connected places (we implement facebook, google, amazon, reddit, yahoo Japan) this never caused any issue

I will continue posting here from times to times, because if not this topic is threatened of being closed after 14 days, but more importantly because this is an actual blocking issue causing projects to be delayed and resulting in additional costs for us.

[Connexinet]

Here is a temporary workaround:

1. Remove the callback URL in the new dev console and enter your use case (don’t hit save yet)
2. Have the legacy console open with your app (but don’t hit edit)
3. Quickly hit save on the new console => edit on the old console => Paste your correct callback URL => Save on the old console

This should have a down town of a second or two, but you will have both use case and callback URL

[MagicalTux]

Thanks, that worked just fine. Now I can only hope the “Application under review.” message changes soon so work can resume.

Ideally this issue would get fixed, but there’s one less pressure here.

[LeBraat]

Hey @chrisdeeming

Thank you for spending the time to explain your situation. I definitely hear you on your points and want you to know that our team is working hard around the clock to improve the various systems and processes that make up the developer portal

These people are mostly not developers and not technical, though with well written instructions, they may just be able to do it.

We have a documentation section that was collaboratively written with both savvy developers and beginners to ensure that the steps make sense for anyone who might be going through the process. If you have any recommendations for ways that we can improve it, I am all ears and will personally work to make sure that we improve the docs. Here is the overview for the developer portal:
https://developer.twitter.com/en/docs/basics/developer-portal/overview

Frankly, though, I think the process for registering on the new portal is hugely convoluted and asks too many questions which are just irrelevant to a normal administrator of our software. Further, the functionality provided is of no interest to them. I think moving the apps stuff to a very developer focused area is a huge mistake.

Everything mentioned here has come up with our team recently. We are actively scoping what work needs to be done to simplify the application process and rework the layout of the developer portal to make more sense for developers who might not be using the portal for the suite of premium products.

First, it is no longer possible to set a callback URL which points to http://localhost . How do you expect developers to be able to quickly and easily test their implementations if they are only testing locally? What’s the point in this arbitrary restriction when all I’d need to do is add a local hosts entry to a FQDN? Or just use http://127.0.0.1 ? It looks like the validation is attempting to force a FQDN here so although you could just whitelist localhost that wouldn’t solve the problem for users who may be wanting to use http://dev or similar.

We have heard from plenty of developers about the difficulties of not being able to use localhost. I will make special note of your argument as it is well defined.

Second, it is no longer possible to use query strings in callback URLs. Although our customers can enable “friendly” URLs, by default a customer URL would be something along the lines of http://example.com/index.php and they would need to redirect to the actual application logic for Twitter which would be http://example.com/index.php?register/twitter in older versions of the software. In newer versions of the software, whether friendly URLs are enabled or not, the callback URL for a “Sign in with Twitter” requeast would be http://example.com/connected_account.php?_xfProvider=twitter . In older versions of the software we have a test suite for signing up with Twitter (and others) and this requires access to a URL similar to http://example.com/admin.php?tools/test-twitter .

We encourage you to not add query strings to your callback URLs in the apps dashboard as we will automatically handle them when you make your API request. In your situation, you should add the following to your apps dashboard:
http://example.com/index.php
or
http://example.com/connected_account.php
or
http://example.com/admin.php

and then use the URLs with the query strings with your POST oauth/request_token request.

I apologize for the inconveniences that you have experienced with our platform recently, but do know that we have to continually update our platform to address security concerns and to ensure that our products are reliable and current. We are continuously working to improve our systems and processes and greatly appreciate your feedback here.

Thank you

[computa_mike]

econd, it is no longer possible to use query strings in callback URLs. Although our customers can enable “friendly” URLs, by default a customer URL would be something along the lines of http://example.com/index.php and they would need to redirect to the actual application logic for Twitter which would be http://example.com/index.php?register/twitter in older versions of the software. In newer versions of the software, whether friendly URLs are enabled or not, the callback URL for a “Sign in with Twitter” requeast would be http://example.com/connected_account.php?_xfProvider=twitter . In older versions of the software we have a test suite for signing up with Twitter (and others) and this requires access to a URL similar to http://example.com/admin.php?tools/test-twitter .

So when you say encourage - does that mean that applications would be rejected with query strings?

[LeBraat]

When I say encourage, I mean that you can currently add query strings via apps.twitter.com, but are not allowed to in the new developer.twitter.com dashboard.

We have mentioned that we will eventually be retiring apps.twitter.com, so we are encouraging developers to avoid using query strings so they don’t have to make changes when we do end up having to manage their apps in the new dashboard.

Keeping things safe - new requirements affecting developers

• • in the future, apps.twitter.com will be retired, and all app management will be consolidated into developer.twitter.com . There will be a 90 day notice period before this occurs.

[system]

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.