Users using Livejournal OpenID are unable to authenticate

Based upon the information that status.net had, changing the "post" to a "get" on the form that redirects appears to be all that's necessary.

The attached patch is working for our site using openid with livejournal. It applies cleanly to both D7 and D6.

Since this bug makes openid non-functional with one of the core open id providers I'm upgrading this to major.

I'm having this issue. Can't authenticate using livejournal.com, tried several Drupal 6 sites. The patch fixes the problem. Already patched 2 sites. Thanks!

Hm. Has someone opened an issue against the Livejournal implementation? Not accepting POST for an indirect communication is definitely against the spec.

For those wondering, it seems that OpenID switched from simple 302 redirects to either GET or POST redirects mainly to work around browsers limitations to the length of URLs [1].

[1] http://stackoverflow.com/questions/34623/why-is-html-form-redirection-us...

Pinged @wojtha in IRC in the hope for a final decision on how to move forward here.

@sun l'll need to do some research, so I'm putting this in my personal queue...

#1: 965718-openid-broken-with-livejournal.patch queued for re-testing.

Reroll for Drupal 7/8. Patch above in #1 should still apply to Drupal 6.

Reading over the linked post in #3, the only reason you *wouldn't* use GET is if you're sending over a large amount of information in the query string. Considering Drupal core's Open ID implementation is only for authentication (not for attribute exchange or anything fancy like that), we shouldn't have any problems with this patch.

Tagging issues not yet using summary template.

It's a shame this has stalled, I see the following that could be done, they are not mutually exclusive:

- just switch to GET instead of POST - if we do that we need a comment to explain why, so marking CNW.
- open a bug report against LiveJournal somewhere for not following the spec and wait for them to fix it.

Todo's seem clear.

Let's implement GET-or-POST based on the size of the payload (FYI: 2000 bytes is widely considered a maximum size for an URL).

#12 esmerel... LJ, lazy bastards...

#13 Damien, yup, that finally sounds like a plan!

The bug on Livejournal has been fixed now:
http://code.livejournal.org/trac/livejournal/changeset/18185

But the bug in the underlying Perl library is still unresolved:
https://rt.cpan.org/Public/Bug/Display.html?id=42202

Using GET when possible (URL longer than 2000 bytes) is probably a good thing anyway (at least there is nothing in the OpenID spec that advices against it). It allows us to skip the intermediate page (flash of white) before redirecting to the OpenID Provider.

If LiveJournal beat us to it, this feels no longer major to me, although still worth doing the switch on 2000 bytes I think.

With this patch we only use POST when needed (= if we are running OpenID 2.x, and the length of the GET URL would exceed the maximum URL length supported by MSIE).

#17: openid-redirect-1.patch queued for re-testing.

#17: openid-redirect-1.patch queued for re-testing.

FYI this issue is sort of the counterpart of #1295096: With Clean URLs enabled: Undefined index: QUERY_STRING in _openid_response() (line 561 of .../modules/openid/openid.inc). That issue is about accepting both GET and POST on the Relying Party (i.e. Drupal) when the user is redirected from the Drupal site to the OpenID Provider, and this issue is about using either GET or POST when the user is redirected the other way, i.e. from the Drupal site to the OpenID Provider.

Reroll.

#25: openid-redirect-3.patch queued for re-testing.

Reroll.

Here is a reroll for your reviewing pleasure :-)

open id module is gone in D8

Patch no longer applies.