@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
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.