That sounds like a good solution, I’ll find some time to get that feature added and release a new version.
In the meantime, if you want a temporary solution, you can replace this line:
$username = $user_data['username'];
with:
$username = explode( '@', $user_info['username'] )[0];
https://github.com/uhm-coe/authorizer/blob/master/authorizer.php#L782
That should replace the username returned from CAS by just the part before any @.
Cheers!
Thread Starter
mrn55
(@mrn55)
Hey Paul,
So to get that user I ended up going near that line you mentioned and did:
if ( array_key_exists( 'uid', $user_data ) ) {
$username = $user_data['uid'];
} else if ( array_key_exists( 'username', $user_data ) ) {
$username = $user_data['username'];
While that got me somewhere, Authorizer still tries to use the email to log users in, with the old CAS solution we had, it used the username. So I also changed:
$user = get_user_by( 'email', $this->lowercase( $externally_authenticated_email ) );
to:
$user = get_user_by( 'login', $result['username']);
Remember this is a CAS only authenticated blog, and it now seems to work, as all over 9000 users were put into this blog via CAS authentication, and all have logins by username. So it “works” now, but obviously it can break when the plugin is updated. You have any thoughts or ideas on what I should do from here? How can my case be satisfied by the plugin so I’m not needing to run some sort of hacky patch along side your plugin?
Thanks,
Neal
I think our plan will be to create a new filter that you can hook into. For now, your solution should be fine. I’ll plan on communicating the filter details to you so you can get it set up before the next version hits, so we can do a seamless transition. Stay tuned!
Looking into this a bit further, I think we misinterpreted the problem. Authorizer uses an email address as the unique identifier to associate a WordPress account with a login from an external service like CAS. We did this for security reasons (e.g., just because your CAS username is admin doesn’t necessarily mean that you should be logged into the admin account in WordPress).
In your case, it sounds like the old CAS plugin you were using created WordPress accounts with no email address, which is where the problem lies. When you set up Authorizer and a CAS user logs in, it uses the email address returned from the CAS server to do a lookup of existing users, and if one matches, it logs in that account. Since your existing WordPress accounts from the old CAS plugin don’t have email addresses, Authorizer assumes there isn’t an existing user, and tries to create a new one. However, this is where we run into the username collision: there is already a WordPress user with the same username, so Authorizer assumes it needs to create a new user with a more specific username, so it creates a new WordPress user with the email address as the username. This is the behavior you were seeing.
Assuming that’s all true, the best course of action would be to create an option that allows you to configure Authorizer to use CAS usernames as the unique identifier linking WordPress accounts to CAS users. This is basically what you did above when you changed the get_user_by() call. (I actually think this is the only patch you made…the other change doesn’t actually do anything because $user_data['uid'] never exists.)
We will probably throw a security warning on that option since we believe it can lead to incorrectly linking accounts.
The upcoming version 2.8.7 will have this option in Authorizer Settings:
View post on imgur.com
Enable that after updating, and that should be enough to replace the patch you had in place.
https://github.com/uhm-coe/authorizer/commit/17f5e98d974c9b1fb27dc49a5b94558572c2059f
Thread Starter
mrn55
(@mrn55)
Right on this sounds cool!
