Updating to v2.0.4 causes authmap view to produce an unexpected error

Created on 15 February 2024, 10 months ago
Updated 19 February 2024, 10 months ago

Problem/Motivation

After updating from v2.0.3 to v2.0.4, visiting the authmap view (admin/people/authmap) causes the unexpected error blank screen. The error in log file is the following:

Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "uid" for route "externalauth.authmap_delete_form" must match "[^/]++" ("" given) to generate a corresponding URL. στην Drupal\Core\Routing\UrlGenerator->doGenerate() (line 209 from /var/www/html/drupal/web/core/lib/Drupal/Core/Routing/UrlGenerator.php).

Steps to reproduce

  1. Update from v2.0.3 to v2.0.4
  2. Visit page .../admin/people/authmap
🐛 Bug report
Status

Active

Version

2.0

Component

Code

Created by

🇬🇷Greece plessas

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @plessas
  • Status changed to Fixed 10 months ago
  • Automatically closed - issue fixed for 2 weeks with no activity.

  • 🇮🇹Italy braintec Perugia, Umbria

    Same error with 2.0.5. Only downgrade to 2.0.3 solve problem.

  • 🇷🇴Romania bboty

    The issue is back after 2.0.5, I can also confirm.

  • Status changed to Active 7 months ago
  • 🇧🇪Belgium svendecabooter Gent

    That's weird.

    Can you check your database, whether you have records in the authmap table that do not have a numeric value for the `uid` column?
    E.g. by running the SQL query SELECT count(*) FROM authmap WHERE uid = ""; and getting a result other than 0?

  • 🇺🇸United States sk33lz

    I ran into almost this same exact issue using the samlauth module. There is a merge request with a working fix available in that issue that might help resolve this issue. See https://www.drupal.org/project/samlauth/issues/3424834 🐛 Error encountered when accessing SAML authentication mapping configuration page Needs review .

  • 🇳🇱Netherlands roderik Amsterdam,NL / Budapest,HU

    Observations from a quick test:

    • In 2.0.3, the UID is present in two properties: $row->authmap_uid and $row->users_field_data_authmap_uid
    • In 2.0.4/5, the UID is present in two properties: $row->uid and $row->users_field_data_authmap_uid
    • I did not see errors in any version. Also not when downgrading.

    Working theory:

    • authmap_uid changed to uid because of the changes to hook_views_data in 2.0.4.
    • In hindsight, I didn't delete / re-import the view after updating to 2.0.5. Maybe users only see the error when they 'newly import' the view on 2.0.5? (Or maybe only when they do not do that... if I made some testing mistake?)
    • Then again... After looking at the changes @svendecabooter made in his commit linked here (that is part of 2.0.5), It seems very strange to me that anyone would still see the reported error. (A blank field: ...sure, maybe. But not the error. The error would only be present in... the dedicated view that samlauth ships.)
    • The two fields in the row are for "the base field" and "the uid field" respectively.
    • I guess using "the uid field" for the link is just as good / better, conceptually, than using "the base field". (Which I didn't think of, when initially coding this thing.)
    • From that perspective, switching to $row->users_field_data_authmap_uid might be better - especially since it sidesteps the change introduced here.

    Also I'm not really sure I agree that 'uid' should be defined 'the base field' in views data, because it's not unique?

    But I don't know all this for sure yet; I'm going to postpone looking at the views code (and any possible effects of the views data change on samlauth) to $some_time when I have more time. So I'm also probably not going to commit the samlauth fix until that time. At that point, I'll likely incorporate the 'fortification' that was committed to 2.0.5 here.

    (This is just a braindump so I don't forget the details until then.)

  • Status changed to Needs review 6 months ago
  • 🇧🇪Belgium svendecabooter Gent

    Thanks for the analysis roderik.
    I have updated the logic for the delete link, to not render if $row->uid is not set.
    So the only reason why it would still trigger an error, is if that value is set, but to an empty string for example.

    I created a merge request that more thoroughly checks if $row->uid actually has a valid value, and also provides a fallback to the $row->users_field_data_authmap_uid value, since that is indeed more consistent among different module releases, from what I can see.

    Can people experience this issue try out this MR fork and see if it resolves the issue for them?
    If not, can you double check you are testing the View provided by ExternalAuth, not by the samlauth module?

  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 8.0 & MySQL 5.7
    last update 6 months ago
    17 pass
  • 🇺🇸United States anthonyroundtree

    I'm getting the same error using v2.0.6 and I'm using saml authentication 8.x-3.10 (as of this posting it's the latest version).

  • First commit to issue fork.
  • Pipeline finished with Success
    14 days ago
    Total: 135s
    #351275
  • 🇦🇺Australia VladimirAus Brisbane, Australia

    Couple of updates:

    • catering for all known uid properties
    • throwing exception instead of returning NULL as parent doesn't cater for NULL
  • Pipeline finished with Success
    14 days ago
    Total: 137s
    #351276
  • 🇦🇺Australia jannakha Brisbane!

    tested

    good to go!

Production build 0.71.5 2024