The latest posts in full-text for feed readers.
Yesterday I learned that Gitea supports login via OpenID, thanks to the work of Sandro Santilli (strk).
While trying OpenID on the public test instance I found a bug with registration after OpenID login.
I mentioned the new OpenID support in the Indieweb IRC channel, and by chance strk was there, too He invited me into the #gitea channel and helped me through the installation and setup of Gitea.
On my server I could reproduce the problem, and found the reason. A minute later, my first patch for the Go-written Gitea was submitted!
Spurred by my enthusiasm, Sandro debugged another OpenID issue he had - the OpenID nonce sent from his OpenID server to Gitea was deemed as "too old" - and found out that it was because the clocks on the two servers were two minutes off; one server did not get its time from NTP.
With OpenID support, nothing holds me back from replacing gitweb with Gitea on my server.
Gitea is a fork of Gogs and happened because the maintainer was away for 3 months and had previously revoked commit access of other contributers. A Gitea blog post states:
Gitea is a community fork of the popular self-hosted Git service Gogs. We're a growing group of former Gogs users and contributors who found the single-maintainer management model of Gogs frustrating and thus decided to make an effort to build a more open and faster development model.
This happened not before trying to convince @Unknwon about giving write permissions to more people, among the community. He rightly considered Gogs his own creature and didn't want to let it grow outside of him, thus a fork was necessary in order to set that code effectively free.
Some people migrated, e.g. Migration von Gogs zu Gitea.
Published on 2017-07-14 in git, openid, web
Since some months I had the problem that doing logins on my SimpleID OpenID server were very slow. phorkie's automatic login took 6-8 seconds, which blocked the browser in that time.
After upgrading all PEAR packages yesterday, OpenID login with phorkie stopped working: The OpenID association request timed out after 3 seconds. Time to investigate the issue.
I was able to create a curl POST request that took 3.6 seconds on my SimpleID instance. With that I was able to track down the functions that were slow with var_dump(); exit(); statements in the code.
I followed the trail from openid_dh_server_assoc() to openid_dh_generate_key_pair() to bignum_powmod() which did some heavy math in vanilla PHP - when PHP's GMP extension is not installed.
Installing Debian's php5-gmp package made it all fast; the login request takes 0.8s now.
To be fair: SimpleID's system requirements document tells us about that issue:
You can also have the following extension enabled for better performance:
gmp
Published on 2016-11-05 in openid, server, web
The IndieWeb movement is much about "code before talk", and on this way wheels are reinvented:
To log into their wiki, you have to have to use indieauth.com which requires you to have an account with a commercial provider (github, twitter, google, app.net etc.). You are also required to add links to them on your homepage.
I don't want an account in silos, and I don't want to link to them from my homepage. I already do have a login service, and this is OpenID. It's decentralized, working and I've got my very own server running on id.cweiske.de, thanks to SimpleID.
Imagine my disappointment when I found out that indieauth.com does not support OpenID as authentication backend . The most indie login protocol is not supported, in favor of silos.
Being unsatisfied with the situation, I sat down yesterday, tried to make sense of the underdocumented indieauth spec (1, 2, 3, 4).
The result is indieauth-openid (github mirror), a IndieAuth-to-OpenID proxy that lets you sign into websites using IndieAuth with your OpenID.
With that, I'm also seemingly the first to run his own IndieAuth server (apart from indieauth.com).
Now all is well and I can use my OpenID server to log into indiewebcamp.com? No. The MediaWiki IndieAuth plugin does not support federation but is hard-wired with indieauth.com :-/
Published on 2014-06-11 in indieweb, openid, php, web
Sourceforge supports OpenID logins since may 2008.
Since at least 2013-10-29 their account login page does not exhibit the OpenID form anymore:
I asked in their support IRC channel, and they told me that I was the first to ask for it; nobody else noticed that they disabled it. You now have to append ?openid to the URL to get the OpenID login form:
They still support OpenID delegation and their OpenID support page does still exist. I wonder how long.
Published on 2014-03-28 in openid, web
TYPO3, the PHP-based content management system, got support for OpenID logins with version 4.3a1 in 2008, which was rolled out in the stable version 4.3.0 in november 2009.
While working on the website for our kindergarden, I took the time to fix a nasty bug and implement some much-needed features. Two of them got merged into TYPO3 6.2, which will be released in march 2014 .
Authentification with OpenID works that way:
Step one usually consists of the user typing in his OpenID identity URL, and the server extracting the identity provider URL from the returned HTML. In this case, the URL given by the user matches his identity URL ("claimed ID") returned by the identity provider after login.
It's also possible to use a generic service provider URL that is simply an XRDS document. In that case, the user's identity URL is different from the XRDS document URL.
Up to now, TYPO3 only supported the first way. It simply failed when the initially given OpenID URL did not match the final one returned by the OpenID server.
Unfortunately, many big providers - Google among them - use this method. But this feature also allows a page to offer a google button, so that users can simply click on it and get logged in.
In march 2011, bug #25322 was reported: Google's OpenID provider URL is https://www.google.com/accounts/o8/id, but the final claimed ID will be something like https://www.google.com/accounts/o8/id?id=xyz, and xyz even is different for the same user when he logs into a second website.
My first patch landed in Gerrit 6 months ago.
After me discussing it with Helmut Hummel, Dmitry Dulepov sent in his own patch that didn't even solve the problem. No explanation given why this is necessary.
Luckily, this second patch was abandoned and after only 13(!) patch sets, my fix was merged into TYPO3 git master.
With Google giving out different claimed OpenID URLs for each domain a user logs into, you simply cannot know in advance which URL you will get - and thus cannot add the OpenID your TYPO3 backend user.
To solve this problem, I made an OpenID wizard for the TYPO3 backend that can be used to assign an OpenID to backend users. It was tracked in bug #49310 and also took 13 patch sets until it finally got merged into TYPO3 core.
Every user and admin is now able to register an OpenID.
Apart from the two mentioned patches, I contributed some more - but they did not get included into the 6.2 LTS release:
Contributing this patches was an incredible frustrating experience. Often, nobody cared and I had to send mails to the mailing list asking for code reviews.
I had to call a core developer to discuss things with him. He promised to look into it, but did not. He told me he has code that does the same; it needs some polishing but would be released soon. It was not.
Then, after 6 months of sending emails to the mailing list begging for reviews, feature freeze settled into the TYPO3 6.2 land. The patches could not be merged anymore.
P.S.: A one-line patch fixing an exit code took 6 months to merge. Talk about resilience.
Published on 2013-12-12 in openid, php, typo3
When clicking an Amazon web services login link today, I noticed some familiar URL parameters: ?openid.assoc_handle=aws&openid.return_to=...
So Amazon is internally using OpenID between its services!
A sane choice, since it enables them to have a separate login server (farm), and thus only have to store (and check) passwords once on this central place. Using a standardized protocol is also a good choice: it is known to work fine out in the internet, and there are well-tested libraries out there to utilize it.
It also follows their internal policy of making every service available via an API :
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
The split-up URL is as follows:
'https', 'host' => 'www.amazon.com', 'path' => '/ap/signin', 'query' => array ( 'openid_assoc_handle' => 'aws', 'openid_return_to' => 'https://portal.aws.amazon.com/gp/aws/developer/registration/index.html', 'openid_mode' => 'checkid_setup', 'openid_ns' => 'http://specs.openid.net/auth/2.0', 'openid_identity' => 'http://specs.openid.net/auth/2.0/identifier_select', 'openid_claimed_id' => 'http://specs.openid.net/auth/2.0/identifier_select', 'action' => '', 'disableCorpSignUp' => '', 'clientContext' => '', 'marketPlaceId' => '', 'poolName' => '', 'authCookies' => '', 'pageId' => 'aws.ssop', 'siteState' => 'awscustomer', 'accountStatusPolicy' => 'P1', 'sso' => '', 'openid_pape_preferred_auth_policies' => 'MultifactorPhysical', 'openid_pape_max_auth_age' => '3600', 'openid_ns_pape' => 'http://specs.openid.net/extensions/pape/1.0', 'server' => '/ap/signin?ie=UTF8', 'accountPoolAlias' => '', 'forceMobileApp' => '0', 'forceMobileLayout' => '0', ), ) ]]>
Published on 2013-11-30 in http, openid, web
SimpleID, my preferred self-hosted OpenID server software, unnerved me for quite a while with the following error message:
HTTP/1.1 400 Bad Request error:Invalid OpenID message. ns:http://specs.openid.net/auth/2.0
This happened after I entered username and password to log into SimpleID, before getting redirected back to the application I wanted to login originally.
Navigating back and reloading that page always worked, but it wasn't nice to get that message in the first way.
I expected the worst after my last OpenID debugging session, but this time it was quite simple.
At first I compared the GET variables that got sent to the login form URL with the ones that were in the POST data when submitting the form. They were equal, although I would have thought otherwise because of the Invalid OpenID message error.
The next step was to find out where this error is being thrown, which was only two nearby lines of code, of which one could be ruled out by thinking. The apparent reason for the error was that $request['openid.mode'] was not set - which is strange, because the POST data definitely contained it.
The situation was now the following:
I had an URL
http://id.cweiske.de/continue?s=eJyFk...
that got rewritten to
/index.php?q=continue&s=eJyFk...
The GET parameters available in PHP only contained q, not s:
array(1) { ["q"]=> string(8) "continue" }
I suspected an error with the Apache rewrite rule, but investigating that didn't yield any results: The rules were fine.
What else could it be? phpinfo() showed me the un-rewritten $_SERVER["REQUEST_URI"], and the rewritten $_SERVER["QUERY_STRING"] completely with the s parameter.
This means that stripping the s parameter happened in PHP itself, and not somewhere earlier. Placing a var_dump($_GET); at the beginning of index.php also showed that s was missing.
Now I remembered Suhosin, any my earlier problems with it. phpinfo() showed me a list of settings, one with the name
suhosin.get.max_value_length => 512
There it was: s was some 600 bytes long, and Suhosin simply stripped it away. After modifying php.ini and reloading Apache, the error was gone.
After discovering the problem's source, I made a patch for SimpleID that checks the suhosin.get.max_value_length setting and opened a bug report for it.
Now I also know that Suhosin reports the error in /var/log/syslog (where nobody looks for apache-related errors):
suhosin[12345]: ALERT - configured GET variable value length limit exceeded - dropped variable 's' (attacker '1.2.3.4', file '/path/to/id.cweiske.de/index.php')
Published on 2013-04-25 in openid, php, server
I use SimpleID as OpenID server software, and it has served me pretty well - except for blogger.com-hosted blogs. Whenever I wanted to comment and authenticate with my OpenID, I got:
Your OpenID credentials could not be verified
or simply
OpenID error
Since web searches did not yield any helpful results (one page even told me to delegate my OpenID to Google since that works), I decided to debug the fscking thing.
At first I had a peek at the server logs for my OpenID url:
74.125.182.31 - - [time] "HEAD / HTTP/1.1" 200 - "-" "-" 74.125.182.31 - - [time] "GET / HTTP/1.1" 200 2127 "-" "-"
So it first tries a HEAD request, and then a GET. Next station was OpenID server domain access log:
74.125.182.39 - - [time] "GET /?q=xrds/cweiske HTTP/1.1" 200 797 "-" "-"
That was it. No further accesses. This can only mean that Blogger chokes on the XRDS file.
This is my XRDS file:
xri://$xrds*simple
http://specs.openid.net/auth/2.0/signon
http://id.cweiske.de/
http://cweiske.de/
http://openid.net/signon/1.0
http://id.cweiske.de/
http://cweiske.de/
]]>
And this is Google's:
http://specs.openid.net/auth/2.0/server
http://openid.net/srv/ax/1.0
http://specs.openid.net/extensions/ui/1.0/mode/popup
http://specs.openid.net/extensions/ui/1.0/icon
http://specs.openid.net/extensions/pape/1.0
https://www.google.com/accounts/o8/ud
]]>
I played around, adding a service with priority 0, adding the server type and ax type - nothing helped.
At last, I removed the xri://$xrds*simple]]> from my file - and voila, it worked!
My XRDS file is valid according to XRDS-Simple 1.0 Draft 1, but as Eran Hammer writes on his XRDS simple overview page:
XRDS-Simple was an early attempt to simplify the XRDS schema for OAuth Discovery. The XRDS-Simple profile removed many of the complex elements in XRDS and defined new parser behavior to make client development easier. However, after a few attempts it became clear that the underlying architecture was incorrect. Instead, the XRI TC which authored XRDS decided to produce a new specification called XRD 1.0.
XRD 1.0 replaces XRDS-Simple and delivers a truly simple resource descriptor format. It is closely aligned with web linking as used in HTML and ATOM, and includes support for only the most common features.
So we do now know that XRDS-Simple is obsolete.
OpenID version 2 uses the Yadis protocol for OpenID server discovery. Section 7.5.2 XRD Schema defines the structure - it's an XRD 1.0 document, and not a XRDS-Simple one.
Conclusion: SimpleID has a bug, Blogger is correct by not accepting an invalid XRD file.
Published on 2012-11-06 in bigsuck, blackbox, openid, server