Problem/Motivation

  • When removing the property 'email' from the skipped properties and configuring a mapping for claim 'email', then the user entity property value is not updated with the new userinfo.

Proposed resolution

  1. Extend the existing property handling in OpenIDConnect::saveUserinfo() for type 'string' to also handle type 'email'.

Remaining tasks

– none –

User interface changes

– none –

API changes

– none –

Data model changes

– none –

Comments

sun created an issue. See original summary.

mario steinitz’s picture

The email address is a very special user property, as it is one of the properties that requires to be unique for all Drupal users.

I anticipate this is the reason, why emails haven't been allowed for property mapping so far.

If we're going to do so now, we should add additional tests for whether the new email address is in use by another user, and raise according exceptions if so.

mario steinitz’s picture

Status: Needs review » Needs work
leksat’s picture

Status: Needs work » Needs review
StatusFileSize
new1.58 KB

@Mario Steinitz good point!

raise according exceptions

Not sure if an exception is required. I implemented it as a Drupal log message.

leksat’s picture

StatusFileSize
new1.77 KB

I implemented it as a Drupal log message.

Well... For some projects it can be pretty critical I think. So here is a version with an exception.

gugalamaciek’s picture

StatusFileSize
new1.75 KB

Patch to use in version 1.0.0.

jcnventura’s picture

Version: 8.x-1.x-dev » 2.x-dev
Status: Needs review » Needs work

Thanks for working on this. It seems a good improvement. However, 1.x will not get any new features, and this is a new feature. The patch needs to be for version 2.x.

  1. +++ b/src/OpenIDConnect.php
    @@ -653,6 +653,32 @@ class OpenIDConnect {
    +                    $account->set($property_name, $userinfo[$claim]);
    

    By this time, $property_name is 'mail', might as well not use the variable.

  2. +++ b/src/OpenIDConnect.php
    @@ -653,6 +653,32 @@ class OpenIDConnect {
    +                    $this->$this->logger->critical(
    

    The double $this is surely an error...

    Also, although this is an error, it surely is not critical. It does not threaten the integrity of the site.

  3. +++ b/src/OpenIDConnect.php
    @@ -653,6 +653,32 @@ class OpenIDConnect {
    +                      'Could not save user info for account %account. Email address %email is already used in account %account_by_mail. An exception will be thrown.',
    

    Let's not reveal the username of the other account. Just use the following message: 'Could not save user info. Email address %email is already used in another account'.

    And simplify the replacement variables, as we only need email now.

  4. +++ b/src/OpenIDConnect.php
    @@ -653,6 +653,32 @@ class OpenIDConnect {
    +                    throw new \RuntimeException('Cannot set account email address in openid_connect_save_userinfo because it is already used in another account.');
    

    Use same message as above, to simplify the life of translators. Or better yet, do not throw an exception at all. Just because we can't map a field should not be a reason for the user to not be able to save the other claims. Please delete this line.

gugalamaciek’s picture

StatusFileSize
new1.38 KB

Here there is patch with improvements suggested by @jcnventura :)

It's for 1.x version.

jcnventura’s picture

Status: Needs work » Needs review

It probably applies already to 2.x. That part of the code hasn't changed much,

pcate’s picture

Status: Needs review » Reviewed & tested by the community

Patch works for me with version 2 of the module.

jcnventura’s picture

Nice to know. I'll test this and probably commit, and implement the change I requested in #7.2, and change the logger message from critical to warning.

Honestly, it's a user that most likely is trying to use OpenID when he already has another account in the system. Hardly the stuff should be above a warning. It maybe should even be a notice.

  • jcnventura committed 92a48a4 on 3.x
    Issue #2989261 by gugalamaciek, Leksat, sun, jcnventura, Mario Steinitz...

  • jcnventura committed 9e365f0 on 2.x
    Issue #2989261 by gugalamaciek, Leksat, sun, jcnventura, Mario Steinitz...
jcnventura’s picture

jcnventura’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.