No fallback when certain Shib headers are not present

[jdpurdyvi]

d64dd2baeb61f4e7422e6aaca242f6324cba5f14 breaks configs that don't provide [username][name]. Could the code fallback to using Shib-Session-ID?

[jdpurdyvi]

Well, I was able to remap the Username attribute to something from our Identity Provider and all is well enough.

[jrchamp]

I'm so sorry @jdpurdyvi! In looking at the code, I was assuming that username was a required mapping. How were you getting around it before? Oh! Do you rely completely on the shibboleth_override_username hook?

[jdpurdyvi]

I suppose so? I would be happy to share specific env details if that's helpful:

• Username was mapped to EDUPERSONPRINCIPALNAME, which provided unique-name@colostate.edu
• Allow Automatic Account Merging (Bypass Username Management) was also enabled
• Accounts were individually created with unique-name as the WordPress account name
• To get v2.4.3 to work I had to change the Username mapping to colostateEduPersonEID which provides the matching unique-name without the @colostate.edu

Automatic login continued to work if I had a valid Shib session from a same-domain site that was still on v2.4.2

[jrchamp]

Ah, I see! It looks like you were using the email-matching to have it map to the correct user. Now that you have the Username mapping set to your unique-name which does match the account in WordPress, you can probably switch from Allow Automatic Account Merging (Bypass Username Management) to Allow Automatic Account Merging (it's a slightly more efficient WordPress lookup).

I'll see what I can do to add a fallback check that mirrors the truly required fields instead of only the username.