I've made the difficult decision to drop support for Twitter authentication on IndieAuth.com. Some time last week, Twitter rolled out a change to the website which broke how IndieAuth.com verifies that a website and Twitter account belong to the same person.
Since I am already in the process of replacing IndieAuth.com with two new websites (lots of discussion on the wiki), it is not worth the effort to do what it would take to fix this for IndieAuth.com.
In order to verify that you are the person behind the URL you initially type in, IndieAuth.com checks your website to find a link to a Twitter profile, then checks that Twitter profile to see if it links back to your website. If there is a match, then you'll see the green button for Twitter on IndieAuth.com.
Twitter rolled out a change that prevents normal HTTP requests from returning actual HTML on Twitter profiles. I'm assuming this is part of their effort to fight bots, but it's unfortunate this use case got caught up in that mess. If you visit your Twitter profile in a browser and click "view source", you'll see something like this now.
Fetching a profile URL with curl now returns an empty HTTP body.
Even if I go through the hoops to make IndieAuth.com set cookies and refresh the page, there's no guarantee that they won't just change this again next week. I don't like playing these games, so instead I am just shutting off Twitter support in IndieAuth.com.
The new version that you'll eventually use to sign in to the IndieWeb wiki is called IndieLogin.com. It is currently in beta, and is not available to other developers, but you can try signing in to the test page there right now. This new version gets around this Twitter problem by not even attempting to fetch Twitter profile pages in the first place.
The new login flow works like this:
This avoids the problem because IndieLogin.com never tries to fetch your Twitter profile HTML. Instead, it uses the API directly. This does mean that you can get into a situation where IndieLogin.com may prompt you with a Twitter button that can fail (if you are logged in to a different Twitter account than the one your website links to). However, it also speeds up the initial login prompt since it doesn't have to go check Twitter before showing you the login button first.
Hopefully I'll be able to launch IndieLogin.com soon so that the lack of Twitter support on IndieAuth.com isn't too annoying. In the mean time, you can authenticate via GitHub or email on IndieAuth.com.
Continuing yesterday's work, today I added support for parsing Twitter URLs to XRay.
There were a couple tricks to make this work. I wanted to make sure that Tweets are always expanded to include the most data possible, and also wanted to avoid needing to make a bunch of HTTP requests. Scraping from the twitter.com website wasn't an option, since some of the data isn't available or would require additional HTTP calls to fetch. (For example I would have to fetch every t.co URL to expand them.) So I set to work using the Twitter API to fetch the tweets.
I didn't want to hit Twitter rate limits by sharing all XRay access from a single account, and I also didn't want to add a database to XRay so that it can continue to be stateless. This meant that the only option was for the XRay client to pass in its own Twitter credentials when fetching twitter.com URLs. This is an acceptable compromise for me, since it keeps XRay simple, and also avoids me needing to officially get a Twitter app approved. If you want to use this feature, you can go to dev.twitter.com and create an app and access tokens for your account right there, which doesn't even involve writing any code. I've updated the XRay readme with further instructions.
Now p3k will include my Twitter credentials when making a request to XRay for a twitter.com URL, and XRay uses my Twitter credentials to fetch the tweet from the API.
So now, whenever I repost something on twitter.com, the contents are expanded and my website shows the full Tweet!
"In a perfect world, we would have been able to use the original URL structure with the hashes for our application, and served both the site and the app simultaneously. This would be the absolute best thing for users of all kinds, and this debate would not be happening."
"Let’s pretend that instead of building a single company, a group of engineers got together and built an ecosystem. Like email, but taking in the lessons we’ve learnt, the new communication modes we’ve stumbled across, in the past decades. Multiple servers and services compete and coordinate in equal measure, advancing the whole and being pushed to their limits. Some servers compete on individual privacy, others compete by exchanging privacy for enriched services. Maybe some services even have Moments, who knows. Space for everyone."