The Net::OpenID::Server perl module that LJ uses appears to be very picky about input, and rejects most request types unless the data comes in as GET parameters (apparently following OpenID 1.1 rules, rather than OpenID 2.0 rules which permit any request to be POSTed but requires that if so, the data must all be in the POST body).
Apparently something got updated on LJ at some point that's either added that behavior or (more likely) added the OpenID 2.0 namespace info to discovery, which tells the Janrain-based OpenID libraries that they should go ahead and do POST requests instead of redirects to GET requests... thus breaking everything. ;)
GET should be just fine for both 1.1 and 2.0 though, and also saves having to sit through that lame autosubmit page.
Switched the authentication submission from checking whether it should redirect to GET or do a form POST, to simply always doing the redirect to GET.
Tested against providers:
* LiveJournal
* Google
* LaunchPad
* identi.ca
The Net::OpenID::Server perl module that LJ uses appears to be very picky about input, and rejects most request types unless the data comes in as GET parameters (apparently following OpenID 1.1 rules, rather than OpenID 2.0 rules which permit any request to be POSTed but requires that if so, the data must all be in the POST body).
Apparently something got updated on LJ at some point that's either added that behavior or (more likely) added the OpenID 2.0 namespace info to discovery, which tells the Janrain-based OpenID libraries that they should go ahead and do POST requests instead of redirects to GET requests... thus breaking everything. ;)
GET should be just fine for both 1.1 and 2.0 though, and also saves having to sit through that lame autosubmit page.
Switched the authentication submission from checking whether it should redirect to GET or do a form POST, to simply always doing the redirect to GET.
Tested against providers:
* LiveJournal
* Google
* LaunchPad
* identi.ca
Introduce a table mapping notices to Twitter statuses. Initialize
this table at checkSchema() time. Save the mapping when we push
or pull statuses. Use the table to determine if a notice has a
Twitter equivalent.
