Error encountered when accessing SAML authentication mapping configuration page

I'm getting the same issue. It looks like the solution Rishi Kulshreshtha created brings the page back.

I'm getting the same issue. It looks like the solution Rishi Kulshreshtha created brings the page back.

Also ran into this issue and can confirm the change in the linked merge request restores access to the page.

This is because of changes made to externalauth.

While I don't doubt that this works,

• I don't know why it works, so I don't know if it will keep working. ($row apparently has two separate properties with the same value. They used to be $row->authmap_uid and $row->users_field_data_authmap_uid. After the update to externalauth 2.0.4, the properties are $row->uid and $row->users_field_data_authmap_uid. OK, but why are there two? Maybe that knowledge will help solve the referenced externalauth issue too. Because it works for me... but... some people are apparently still having issues?)
• I want to keep the code in sync with externalauth. That means looking at the changes in 2.0.4 and possibly incorporating them. But I'm not sure having uid be the base_field makes sense there, given that it's not necessarily a unique value?

It may well be that the solution in this MR is the right one, but I want to doublecheck if the 'parent issue' can be closed, first (or at least, that it won't affect us).

If you want to fix the issue now: downgrade externalauth to 2.0.3. There are no changes since 2.0.3 except for the view (which my view is based on) and gitlab / phpcs.

MrKennedy → changed the visibility of the branch 3424834-error-encountered-when to hidden.

I have same problem with these versions samlauth: 8.x-3.9 & externalauth: 2.0.5 and that merge request !18 is solving my problem.

Probably should wait for the next release of externalauth and up the minimum requirement to that release. That way if you see this error and update samlauth, it'll update externalauth too.

Thanks, that's a good idea. There's no reason not to update that minimum requirement.

I'm still keeping this issue open, to think about (including the linked externalauth issue) when I have time.

vladimiraus → changed the visibility of the branch 3424834-error-encountered-when to active.

vladimiraus → changed the visibility of the branch 3424834-error-encountered-when to active.

Updated to cater for all known properties.

tested
good to go

I created a simple patch based on 8x.3.10.
Current issue is there is no autmap_uid property on $row but it iseems $row->uid is available and can be used.

Patch fixed the issue for me.

This has grown too complicated to administer properly to everyone's satisfaction:

• A new issue was opened that, I think, also fixes the issue. That is: while this issue was already/still open, but before the second MR was created.
• A new patch was added in January, but it doesn't say why / why the MR wouldn't be good.
• The MR in this issue was more or less copied to externalauth 🐛 Updating to v2.0.4 causes authmap view to produce an unexpected error Active (which I reviewed and which was committed to v2.0.7) but was sloppy; it contained references to samlauth instead of externalauth. I still doubt that it was actually needed, because 'uid' should have worked fine for the externalauth case.

In the end,

• I re-investigated my old code, and improved it so that it doesn't rely on hardcoded alias names at all - in externalauth 📌 Improve views integration Active
• I stripped code from this module as far as possible (as long as #3503865 is not committed to a released version yet) and committed that. (I did include the change that is also in patch #17 == the 🐛 Authmap view is breaking - admin/config/people/saml/authmap Active MR. While investigating, I saw that users_field_data_authmap_uid is neither necessary, nor theoretically correct. If that causes issues for anyone: comment.)

roderik → closed merge request !18

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