Bug #25322

OpenID login does not work with Google

Added by Felix Nagel almost 11 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Miscellaneous
Target version:
-
Start date:
2011-03-15
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Since google changed its OpenID URLs a few days ago there is a problem with the authentication with TYPO3.

Reproduce the problem:
Set google OpenID URL (username based or generic) in user preferences, log out, enter URL click login, -> redirect to google, enter google credentials, -> redirect to your TYPo3 installation without successful auth.

It worked fine with https://profiles.google.com/user.name but google killed that URL and later redirected it to the generic endpoint https://www.google.com/accounts/o8/id. Both work as OpenID URL on other platforms but not with TYPO3. Perhaps there is an issue with the redirect? Any idea what the PHP errors are about?

Tried with multiple installations (TYPO3 4.4 and 4.5.2).
PHP error messages in BE: http://pastebin.com/uC6ADaL0
Seems to be not related to this issue: 13584
Others have problems too (see commets): http://typo3blogger.de/neue-features-in-4-3-teil-6-openid/
Google OpenID infos: http://code.google.com/intl/de-DE/apis/accounts/docs/OpenID.htm
(issue imported from #M17945)


Files

25322-47.patch (643 Bytes) 25322-47.patch Ivan Dharma Kartolo, 2012-09-01 13:17
all.xrds.php (539 Bytes) all.xrds.php Christian Weiske, 2013-06-25 12:41

Related issues

Related to TYPO3 Core - Bug #49310: Wizard to add OpenID to backend userClosedChristian Weiske2013-06-21

Actions
Blocks TYPO3 Core - Feature #49399: OpenID provider buttonsClosed2013-06-25

Actions
Blocks TYPO3 Core - Feature #44127: OpenID login: automatically create backend user accountsClosed2012-12-19

Actions
#1

Updated by Philipp Gampe almost 11 years ago

How about reading the error message?

You have to include /dev/random and /dev/urandom to allowed paths.

This is a configuration issue on your server.

#2

Updated by Felix Nagel almost 11 years ago

It has worked before and is working with other OpenID providers. Looks not like an server configuration issue to me.

#3

Updated by Philipp Gampe almost 11 years ago

The PHP errors are a configuration issue. Your hoster might have changed configuration.

Actually your PHP can not get random bytes. This might be one reason why it failes.
Ask your hoster if they can add the paths to allowed paths and then see if if works again.

#4

Updated by Felix Nagel almost 11 years ago

I will ask my hoster even if I cant understand why my server configuration could be wrong for googles openid service only. It should work for all providers or none, shouldnt it?

Would you please try to explain "PHP errors are a configuration issue" as I do not understand the meaning.

#5

Updated by Philipp Gampe almost 11 years ago

Ok, let me try to explain.
Your server is configured that it only allows access to some path of the file systems. If you PHP process tries to access a path which is not allowed, you will get the mentioned error.

In your case you can not access the random bytes devices. Whether is is the problem with your login or not - I don't know.
But it is very likely that OpenID needs some random bytes for encryption.

For further informations, someone must consult the actual code.

BTW: If you don't know whether a problem is a TYPO3 bug or not, you might better ask in newsgroup first.

#6

Updated by Felix Nagel almost 11 years ago

Thanks for your help, really appriciated!

I forgot to mention that Ive tested 8 different Installations on about 4 different Servers. It fails on every system but only one Installation logs the open_basedir restriction error. So it seems this is not a server configuration problem.

Logically it must be a TYPO3 OpenID implementation error. Google OpenID works on all platforms but TYPO3.

#7

Updated by Felix Nagel almost 11 years ago

Ive got feedback from my hoster: Access to /dev is not allowed for security reasons. The support guy is pretty sure access to /dev is not normal behavior.

#8

Updated by Felix Nagel over 10 years ago

  • Target version deleted (0)

Here is another issue which reports the error message in syslog (my pastebin link above is broken): http://bugs.typo3.org/view.php?id=17784

#9

Updated by Alexander Grein over 10 years ago

Are there any news about this issue? I can confirm the problems on my system.

#10

Updated by Benjamin Strilziw over 10 years ago

I've got the same problem with my Google OpenID.
At some point I was so annoyed so I changed the OpenID-provider (to Verisign Labs) and it works fine. But it's not ideal to have one OpenID for TYPO3 and another one for everything else.

Hope you can fix this.

#11

Updated by Felix Nagel about 10 years ago

Any progress on this issue?

I thinks its pretty obvious its not a specific server issue as every other OpenID Provider works without problems in TYPO3 AND Google OpenID works with any other system except TYPO3.

Please see here (and feel free to add some more test in the spreadsheet):
https://docs.google.com/spreadsheet/ccc?key=0AoeFGgKVpeJsdHJ6eW1rUGdrRHVzNDQ0N2J2VzdNR1E

Please note: 2 of 3 tested TYPO3 installations (which means three different server and 3 different hoster) throw the "open_basedir restriction" warning even when OpenID works.

#12

Updated by Steffen Gebert about 10 years ago

  • Category set to 1134
#13

Updated by Peter Rauber over 9 years ago

Same problem here. Would be nice to use google as an OpenID-Provider to log into my TYPO3-backends.

#14

Updated by Thomas Fricke over 9 years ago

Indeed, OpenID via Google would be great, as i use the Google services quite a lot.

#15

Updated by Jonas Enders over 9 years ago

Same problem here (TYPO3 4.7.3):

Install extension openid.
Enter OpenID identifier for BE-User:
https://plus.google.com/xxxxxxxxxxxxxxxxxxxxx/
Logout
Login using OpenID "https://plus.google.com/xxxxxxxxxxxxxxxxxxxxx/"
Redirect to https://accounts.google.com/o/openid2/...
Login
Redirect to http://example.com/typo3/

No error, no login.

I downloaded the library php-openid, which is used by TYPO3 extension openid and checkt functionality with examples/consumer/index.php. The example script successfully verified identity:

"You have successfully verified https://profiles.google.com/xxxxxxxxxxxxxxxxxxxxx as your identity.
No PAPE response was sent by the provider."

#16

Updated by Ivan Dharma Kartolo over 9 years ago

Hi all,

I can locate the problem. Patch is coming. :)

Ivan

#17

Updated by Gerrit Code Review over 9 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/14254

#18

Updated by Ivan Dharma Kartolo over 9 years ago

following ist patch for 4.7 (might also work for all 4.x, not tested yet) Patch for master (6.0) is push in gerrit :)

Google OpenID URL is https://www.google.com/accounts/o8/id
But after redirecting to Google and back to the TYPO3, Google gives the following OpenID URL as parameter back to the TYPO3

https://www.google.com/accounts/o8/id?id=xyz

The problem is the regex in openid ext, which normalized the URL (see in sv1 the function getAdjustedOpenIDIdentifier), says that the URL doesn't match.

Patches are made during the TYPO3 Code Sprint in Stuttgart 2012 (#t3csst12)

#19

Updated by Ivan Dharma Kartolo over 9 years ago

Update on the patch.

The patch "could" be wrong.
Google OpenID URL is https://www.google.com/accounts/o8/id (without any user specific data)
but after signing in, Google gives the identification URL https://www.google.com/accounts/o8/id?id=xyz, where xyz is the identification of the user.
Since the user doesn't know the xyz and couldn't enter this in be_user table beforehand, there's no way for openid extension to search the be_users based only on the OpenID URL.

#20

Updated by Ivan Dharma Kartolo over 9 years ago

some interesting facts:

Google has multiple OpenID URL:

  1. https://profiles.google.com/USER_ID
  2. https://plus.google.com/USER_ID
  3. https://www.google.com/accounts/o8/id

To find your USER_ID just go to profiles.google.com. Your USER_ID is the long number in the middle. Mine is 108295771337906844764

Here are the problems.
if you use the OpenID 1 and 2, you'll get https://profiles.google.com/USER_ID as OpenID identity URL, which will be used by openid extension to search in the be_users table
If the 3rd URL (https://www.google.com/accounts/o8/id) is used, you'll get https://www.google.com/accounts/o8/id?id=xyz as OpenID identity URL. The problem is id=xyz is site and user specific and it's unknown for the user or TYPO3.

The third URL (https://www.google.com/accounts/o8/id) is only useful for self-registering user, so the (https://www.google.com/accounts/o8/id?id=xyz) can be saved in the database and the user uses only (https://www.google.com/accounts/o8/id) on login.

For BE-User, only the first URL can be used (https://profiles.google.com/USER_ID), since the second one produces profiles.google.com as identity URL.

So it's not a bug in the extension, but more a problem of variation Google providing.

#21

Updated by Felix Nagel over 9 years ago

Hey Ivan, thanks for your effort in order to fix this annoying problem!

I can confirm Google OpenID works when using the first URL (https://profiles.google.com/USER_ID). This works even with or wihout your patch but only with the "profiles" URL. Tested with TYPO3 4.7 and 4.4, so I assume this works with all versions.

ps: I understand the problem with the generic OpenId endpoint, but how do other system handle this? Perhaps by just storing the redirected url as well?

#22

Updated by Ivan Dharma Kartolo over 9 years ago

Hi Feilx,

I would say so:
  1. there's a register field on the Site
  2. User put "https://www.google.com/accounts/o8/id" as login credentials (or perhaps the URL is just a link and the user clicks it)
  3. OpenID mechanism logs the user to Google (with redirect to google login page)
  4. at this point, google gives the OpenID URL with an ID as GET-Param back to the system
  5. the system creates new user and saves this URL (with ID). The user doesn't know anything about this ID-Parameter. Only our system and Google know about the ID Param.
  6. After this process, the user can log themself in with the URL https://www.google.com/accounts/o8/id

There's an option to ask Google to give the User Gmail address during the openID login process, but I think to identify a user based on the email is really bad workaround and perhaps the user doesn't have their email in be_user

cheers,

Ivan

#23

Updated by Michael Bakonyi almost 9 years ago

Hi Ivan,

thx a lot for pointing this out! I can confirm the OID-login working with the link https://profiles.google.com/PROFILEID and without your patch implemented.

Nevertheless, the login should also work with the link https://plus.google.com/PROFILEID/posts, I think, as it is stated by e.g. openid.net as regular openid-link: http://openid.net/get-an-openid.

Cheers,
Michael

#24

Updated by Christian Weiske over 8 years ago

The source of the problem is how TYPO3 handles the OpenID login:

  1. User gives OpenID URL, clicks Login
  2. TYPO3 normalizes URL
  3. TYPO3 looks for URL in database.
    1. If no user with that OpenID URL is found, authentication fails
    2. If a user is found, the real OpenID auth process begins by sending the user to the OpenID server.

This is unfortunately not how OpenID works.

OpenID makes a distinction between the OpenID provider URL and the OpenID identifier. You may begin authentication with either one.

For Google, the provider URL for all users is https://www.google.com/accounts/o8/id (except they use their g+ profile url), the user-specific OpenID identifier is only returned after a successful login at google.

So only at this stage, TYPO3 can decide if the user exists in the database - because earlier, it may only have gotten the OpenID provider URL, not the OpenID identifier URL.

Another issue with google is that they return different OpenID identifiers for the same account for different OpenID consumer domains. This means that when logs into example.*org*, example.org will get a different identity than example.net gets.
This is done for security reasons so that you stay relatively "anonymous" and can't simply compare the user databases of different websites.


So to make it short: TYPO3 may not check if the OpenID URL exists in the local user database before doing OpenID authentication. Only after successful OpenID authentication, the identifier URL is known. Only then TYPO3 may check if the user is in the database.


As soon as this is implemented correctly, we can offer big fat service provider buttons like stackoverflow does on its login page. People just click onto it, sign in at their provider and don't have to type a single letter.

#25

Updated by Gerrit Code Review over 8 years ago

Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#26

Updated by Helmut Hummel over 8 years ago

  • Status changed from Under Review to Needs Feedback

Christian Weiske wrote:

  1. User gives OpenID URL, clicks Login
  2. TYPO3 normalizes URL
  3. TYPO3 looks for URL in database.
    1. If no user with that OpenID URL is found, authentication fails
    2. If a user is found, the real OpenID auth process begins by sending the user to the OpenID server.

This is unfortunately not how OpenID works.

This is exactly how OpenID works!
The "problem" is, that there is also a second way how OpenID can work.

These are the two option for the beginning of an OpenID authentication

  1. The user who wants to log in to a relying party presents a claimed identifier
    1. In this case, the OpenId provider URL is fetched during discovery (The claimed identifier points to a URL where this data can be retrieved)
  2. User enters an OP (OpenId Provider) Identifier
    1. In this case the OP selects the identifier in the login process and returns it in the response to the RP (relying party).

OpenID makes a distinction between the OpenID provider URL and the OpenID identifier. You may begin authentication with either one.

Yes, but they are a totally different story for the relying party!

For Google, the provider URL for all users is https://www.google.com/accounts/o8/id (except they use their g+ profile url), the user-specific OpenID identifier is only returned after a successful login at google.
So only at this stage, TYPO3 can decide if the user exists in the database - because earlier, it may only have gotten the OpenID provider URL, not the OpenID identifier URL.

The problem is: How to identify the user in TYPO3?

Another issue with google is that they return different OpenID identifiers for the same account for different OpenID consumer domains. This means that when logs into example.*org*, example.org will get a different identity than example.net gets.
This is done for security reasons so that you stay relatively "anonymous" and can't simply compare the user databases of different websites.

...especially if this is true? How can we identify the user who has just authorized with the google open id server?


So to make it short: TYPO3 may not check if the OpenID URL exists in the local user database before doing OpenID authentication. Only after successful OpenID authentication, the identifier URL is known. Only then TYPO3 may check if the user is in the database.


So anyone needs to know the openID URL for the user and put it in the user field? How to know this URL?
What about the fact that it changes for domains? A user can login in the dev system but the same user cannot login to another system (other domain)?

As soon as this is implemented correctly, we can offer big fat service provider buttons like stackoverflow does on its login page. People just click onto it, sign in at their provider and don't have to type a single letter.

I'm in favor of implement this correctly, but just removing the check from getUser is no solution. It only mixes the two options of the OpenID protocol, but does not bring any benefit.

If the user already knows his/her google OpenId, he or she can specify it in the user record and OpenID discovery should work without any change of the code on our side.
Of course then the full URL needs to be specified during login

#27

Updated by Christian Weiske over 8 years ago

Yes, but they are a totally different story for the relying party!

No. As RP, you just pass the given identifier to OpenID lib (which contacts the OpenID server) and let the login process happen. After that process finished, you have user data. Then you can check if the user is in your DB.

The current OpenID implementation in TYPO3 handles only a special case of OpenID login, when given OpenID and claimed ID are exactly the same.

How can we identify the user who has just authorized with the google open id server?

By their OpenID URI (claimed_id) of course.

I'm in favor of implement this correctly, but just removing the check from getUser is no solution. It only mixes the two options of the OpenID protocol, but does not bring any benefit.

The check is not removed. It's still there, but only after the OpenID login

So anyone needs to know the openID URL for the user and put it in the user field? How to know this URL?

That's a problem indeed. TYPO3 could show the full OpenID URL when the claimed_id is not in the TYPO3 user database - that way the user can give the admin his OpenID to register.

What about the fact that it changes for domains? A user can login in the dev system but the same user cannot login to another system (other domain)?

The correct solution to this problem is to allow several OpenID URIs for a user. Having several OpenIDs also helps against providers shutting down.

If the user already knows his/her google OpenId, he or she can specify it in the user record and OpenID discovery should work without any change of the code on our side.

For google you don't know your OpenID in advance, only after you did an OpenID login. That makes it impossible to use Google with TYPO3 for now.

#28

Updated by Ivan Dharma Kartolo over 8 years ago

Christian Weiske wrote:

If the user already knows his/her google OpenId, he or she can specify it in the user record and OpenID discovery should work without any change of the code on our side.

For google you don't know your OpenID in advance, only after you did an OpenID login. That makes it impossible to use Google with TYPO3 for now.

according to OpenID page is Google Profile Url (my is https://plus.google.com/108295771337906844764/) an OpenID URL. I used to be using this, but just now it just redirected to TYPO3 login page not BE.

#29

Updated by Philipp Gampe over 8 years ago

IMHO we should implement this for 6.2 only (as FEATURE). Then we can change the db field to text and allow multiple urls separated by newlines. This makes it a bit more tricky to query the database, but should work nevertheless.

We might also provide a wizard in the user settings module to register your own openid identifier based on an openid provider.

#30

Updated by Gerrit Code Review over 8 years ago

  • Status changed from Needs Feedback to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21501

#31

Updated by Dmitry Dulepov over 8 years ago

  • TYPO3 Version changed from 4.5 to 6.2

I just sent a patch to Gerrit that solves the issue. I am sure there will be some rejects, so you may go and perfect the patch. Make sure to read the commit message. There are important notes for Google.

#32

Updated by Christian Weiske over 8 years ago

Dimitry, why do you think it is important to verify the OpenID URL before starting the OpenID login process?

Why is the approach wrong to first do the OpenID login process and only then check against the user database?

#33

Updated by Gerrit Code Review over 8 years ago

Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#34

Updated by Christian Weiske over 8 years ago

So anyone needs to know the openID URL for the user and put it in the user field? How to know this URL?

That's a problem indeed. TYPO3 could show the full OpenID URL when the claimed_id is not in the TYPO3 user database - that way the user can give the admin his OpenID to register.

I've opened issue #49310 for this problem, in which we'll implement a wizard for the backend user's OpenID URL field.

#35

Updated by Gerrit Code Review over 8 years ago

Patch set 3 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#36

Updated by Christian Weiske over 8 years ago

Btw, everyone can do the same as google does with his own OpenID provider. Just provide an XRDS file that announces your OpenID provider, see the attached all.xrds.php.

Use the file's URL in the OpenID input file, then log in and your claimed ID is different than the file's ID:

Input: http://id.bogo/all.xrds.php
Claimed ID: http://id.bogo/maxbo.htm

#37

Updated by Gerrit Code Review over 8 years ago

Patch set 4 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#38

Updated by Christian Weiske over 8 years ago

Testaccount for those people without an OpenID account:

OpenID: http://hidden.cweiske.de/typo3test.htm
User: typo3test
Pass: typo3foobarbaz

If you want to reproduce the Google OpenID issue, use the following
OpenID URL:
http://cweiske.de/openid.php

#39

Updated by Christian Weiske over 8 years ago

Phone call with Helmut:

It is RECOMMENDED that the form field be named "openid_url" so User-Agent's will auto-complete the End User's Identifier URL in the same way the eCommerce world tends to use conventions like "address1" and "address2".

#40

Updated by Gerrit Code Review over 8 years ago

Patch set 5 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#41

Updated by Gerrit Code Review over 8 years ago

Patch set 6 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#42

Updated by Gerrit Code Review over 8 years ago

Patch set 7 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#43

Updated by Gerrit Code Review over 8 years ago

Patch set 8 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#44

Updated by Gerrit Code Review about 8 years ago

Patch set 9 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#45

Updated by Gerrit Code Review about 8 years ago

Patch set 10 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#46

Updated by Gerrit Code Review about 8 years ago

Patch set 11 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#47

Updated by Gerrit Code Review about 8 years ago

Patch set 12 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/21373

#48

Updated by Anonymous about 8 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#49

Updated by Benni Mack over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF