Logging in resets role to "Editor" instead of "Administrator" or "Shop Manager"

[d19dotca]

@girish said in Logging in resets role to "Editor" instead of "Administrator" or "Shop Manager":

wp --format=json option get authLDAPOptions

Seems to be the same in both sites:

Working:

{
	"Enabled": "1",
	"CachePW": false,
	"URI": "ldap:\/\/172.18.0.1:3002\/ou=users,dc=cloudron",
	"Filter": "(username=%s)",
	"NameAttr": "givenName",
	"SecName": "sn",
	"UidAttr": "username",
	"MailAttr": "mail",
	"WebAttr": "",
	"Debug": false,
	"DefaultRole": "editor",
	"GroupEnable": false,
	"GroupOverUser": false,
	"Version": 1,
	"URISeparator": "",
	"StartTLS": false,
	"Groups": {
		"administrator": "",
		"editor": "",
		"author": "",
		"contributor": "",
		"subscriber": "",
		"wpseo_manager": "",
		"wpseo_editor": ""
	},
	"GroupSeparator": "",
	"GroupBase": "",
	"GroupAttr": "",
	"GroupFilter": "",
	"DoNotOverwriteNonLdapUsers": false
}

Non-working:

{
	"Enabled": "1",
	"CachePW": false,
	"URI": "ldap:\/\/172.18.0.1:3002\/ou=users,dc=cloudron",
	"Filter": "(username=%s)",
	"NameAttr": "givenName",
	"SecName": "sn",
	"UidAttr": "username",
	"MailAttr": "mail",
	"WebAttr": "",
	"Debug": "1",
	"DefaultRole": "editor",
	"GroupEnable": false,
	"GroupOverUser": false,
	"Version": 1,
	"URISeparator": "",
	"StartTLS": false,
	"Groups": {
		"administrator": "",
		"editor": "",
		"author": "",
		"contributor": "",
		"subscriber": "",
		"customer": "",
		"shop_manager": ""
	},
	"GroupSeparator": "",
	"GroupBase": "",
	"GroupAttr": "",
	"GroupFilter": "",
	"DoNotOverwriteNonLdapUsers": false
}

The expected differences are just the group names as the one site is a WooCommerce site so it has customer and shop_manager roles, and I don't have the one SEO plugin so it's missing the wpseo_* roles. Other than debug, they're basically the same.

[d19dotca]

I can verify that in the database they have the right roles assigned too (it isn't missing a role or anything like that). Additionally, I see from the GitHub PR which seems to have introduced the role change seems to basically just make it so it can search for the actual WP role in case it has multiple values stored in there it can ignore the ones unrelated and get the one that's related, where-as before it apparently only ever took the first role mentioned from what I understand. Can't see how this change breaks it though as the roles exist in both instances for all users, and only one in each too so it isn't even affected by the original issue the PR was meant to address. https://github.com/heiglandreas/authLdap/pull/209/files

[d19dotca]

I just realized in my testing prior I had basically reproduced it in my WooCommerce sites since they have the most complaints of the issue due to the Shop Manager's logging in to find no WooCommerce panel. The other sites really only have me logging in (and on top of that I usually login via MainWP which apparently sidesteps this issue completely, not triggering something that the AuthLDAP plugin is using to reset the role to Editor).

I'm going to try to update this plugin one by one on my customer's sites from least impacting first and see if I can reproduce this on any non-WooCommerce sites in case there's something about WooCommerce and the AuthLDAP plugin that don't work together now.

[girish]

@d19dotca actually, since you narrowed the behavior down to https://github.com/heiglandreas/authLdap/commit/a175571fb95f4e33128bd48d322438f78e440e7 , that bit of code depends on wp_capabilities . Maybe that's what is different in both the instances.

I think SELECT meta_key, meta_value FROM wp_usermeta WHERE meta_key = 'wp_capabilities' . From a casual reading, it seems that if it's not an array, the behavior has changed.

[d19dotca]

@girish said in Logging in resets role to "Editor" instead of "Administrator" or "Shop Manager":

SELECT meta_key, meta_value FROM wp_usermeta WHERE meta_key = 'wp_capabilities'

Good idea! To be honest though I'm just guessing that's the change responsible for the change in behaviour, I'm not 100% certain.

Working site:

mysql> SELECT meta_key, meta_value FROM wp_usermeta WHERE meta_key = 'wp_capabilities';
+-----------------+---------------------------------+
| meta_key        | meta_value                      |
+-----------------+---------------------------------+
| wp_capabilities | a:1:{s:13:"administrator";b:1;} |
+-----------------+---------------------------------+
1 row in set (0.00 sec)

Non-working site:

mysql> SELECT meta_key, meta_value FROM wp_usermeta WHERE meta_key = 'wp_capabilities';
+-----------------+---------------------------------+
| meta_key        | meta_value                      |
+-----------------+---------------------------------+
| wp_capabilities | a:1:{s:13:"administrator";b:1;} |
| wp_capabilities | a:1:{s:8:"customer";b:1;}       |
| wp_capabilities | a:1:{s:12:"shop_manager";b:1;}  |
| wp_capabilities | a:1:{s:8:"customer";b:1;}       |
| wp_capabilities | a:1:{s:8:"customer";b:1;}       |
| wp_capabilities | a:1:{s:8:"customer";b:1;}       |
| wp_capabilities | a:1:{s:8:"customer";b:1;}       |
| wp_capabilities | a:1:{s:8:"customer";b:1;}       |
| wp_capabilities | a:1:{s:8:"customer";b:1;}       |
+-----------------+---------------------------------+
9 rows in set (0.00 sec)

Now the administrator role at top of both is my account, and the value seems identical in them.

[girish]

@d19dotca I guess you can add user_id to the SELECT statement too.

I am out of ideas otherwise Does woocommerce itself have some idea of login role or something?

[d19dotca]

@girish Okay, I was able to manually update the plugin in about 12+ sites without issues, they were non-Woocommerce sites. On every WooCommerce site I manage (4 of them), I ran into the same issue as originally reported.

So I guess the crux of the issue isn't necessarily the plugin all on it's own which may be why it works for some and not others... it's a combination of the plugin's code change plus something to do with WooCommerce, though I have no idea what that'd be exactly. There's other roles added in WooCommerce but that only touches newer users etc, not my original administrator account for example. Very strange.

I guess I may need to just report this upstream.

[d19dotca]

@girish @fbartels @marcusquinn - I just filed an issue in GitHub for the AuthLDAP plugin here, please feel free to add your thoughts or subscribe to it if you'd like updates as well: https://github.com/heiglandreas/authLdap/issues/221

[fbartels]

@d19dotca thanks for opening the issue. I can confirm that i see this behaviour on my two WordPress installs (one prod one testing) which also has woocommerce installed. Since these websites are not really in production yet i have not tried to dig deeper into it (and everybody trying to login as admin also has cli access to easily upgrade their account again).

In my test it felt like the role was changed a bit after the actual login. E.g. i notice i am not and admin, i change the role of the account, i try again the next day and am only an editor again.

[girish]

@d19dotca Looks like there is a fix upstream, can you guys try? I can update the package as needed.

[fbartels]

Hi @girish,

I can confirm that after updating the plugin the user role is no longer reset after logging in.

[girish]

@fbartels thanks! I will update the packages.

[girish]

Both packages are now updated.

[d19dotca]

I just tried it, works great. Glad we got it sorted. Thanks for the help everyone.