TYPO3 Core

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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

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."

Hi all,

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

Ivan

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.

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.

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?

Hi Feilx,

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

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

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 foo@gmail.com 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.

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

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.

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.

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.

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?

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

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.

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

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

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

Phone call with Helmut:

• Schema-less login still has to be possible (current patch requires http:// or https://)
• We move the OpenID URL to a new form field openid_url, as recommended by the OpenID specification anyway: http://openid.net/specs/openid-authentication-1_1.html#anchor6 :

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".

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

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

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

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

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

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

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

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