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

d19dotca

Has anyone experienced an odd issue where when they login using the <host>/wp-admin login page, they login successfully but under the Editor role instead of a different role they may have had?

I think the issue for me is that it's assigning any LDAP users as "Editor" even if it's my Cloudron administrator account. So I have two users (myself and a customer who's supposed to be a Shop Manager role for her WooCommerce store), and whenever they logged in they'd find themselves missing access to WooCommerce. I have put it back a couple of times now to Shop Manager but it seems after a time or two of logging in they find themselves in the same spot. So I realised... I always login via MainWP directly (much easier in many cases as I'm often in there already), and it works fine for me, however when I logged in manually to their site, I too saw I was suddenly made an administrator user.

Using the WP CLI, I was able to see before I had the administrator role, then after logging in I'd run the same WP CLI command suddenly it's set to Editor instead.

I feel like I should have come across this before though, and oddly enough I'm not experiencing this with any other client sites yet to my knowledge.

Still investigating this but figured I"d throw this out here for any input, and if I happen to resolve it myself then I can update this for others who may find it helpful.

root@7042fc52-0629-4c39-8fea-ba11370da8f7:/app/code# wp user list

d19dotca

Wondering if this has to do with the LDAP plugin update ("Update LDAP plugin to 2.5.1" - https://forum.cloudron.io/post/43246)

d19dotca

I can confirm I see this on other sites now too actually, so it's not this one site. Since this wasn't an issue until recently, my gut tells me this has something to do with that AuthLDAP update. Going to try downgrading that plugin and see if that helps at all.

From the authLDAP plugin GitHub release page (https://github.com/heiglandreas/authLdap/releases) (v2.5.1): Ignore the order of capabilities to tell the role. In addition the filter editable_roles can be used to limit the roles

d19dotca

Confirmed - the authLDAP plugin seems to be the root cause**. If I revert back to the previous version of the authLDAP plugin, the issue no longer remains / is not reproducible, and upgrading again to the latest version of the authLDAP plugin presents the issue again.

@girish - You may want to try and reproduce this too, and if you can then we know that we may need to issue an image update which uses the previous version of that plugin. I'm surprised nobody else has reported this yet, so I'm a bit cautious in my findings for now, so wouldn't mind someone else validating this please.

This appears to be the PR in the authLDAP plugin that introduced the behaviour: https://github.com/heiglandreas/authLdap/commit/a175571fb95f4e33128bd48d322438f78e440e77

In my tests, reverting to v2.4.1 of the authLDAP plugin worked: https://github.com/heiglandreas/authLdap/archive/refs/tags/2.4.11.zip

girish

Thanks for bisecting the issue. Let me see how to fix this.

d19dotca

@girish Just wanted to follow-up on this one... was this reproducible on your end too or does this look like a "me" issue instead?

fbartels

@d19dotca I've noticed this behaviour last week as well btw.

d19dotca

@fbartels - Thank you for confirming. I'm glad it's not just me! haha. I was surprised nobody else had reported it here so figured it was maybe just me but then after my testing thought it must affect others too. Needed that sanity check, lol.

@girish - I think you may want to consider pushing a newer image with an older version of the authLDAP plugin to prevent more issues for people caused by that plugin.

For myself, as I've removed auto-updates on everything and manage it all centrally through MainWP, I've set that update to "Ignore" now so that it kind of goes away and I think I will simply manually update for the next version of it whenever it is to test it out better next time (I usually do but that plugin in particular rarely gave issues so it was usually safe to update without testing much - lesson learned now).

girish

@d19dotca I tried this now, but I can't quite reproduce this. Here's what I did:

Logged in as admin. Change the default role to 'Admin'

Then, I logged in as my Cloudron username into WP. It is administrator.
I have logged out and in many times, still admin.

Did I misunderstand the bug report?

girish

And here's the WP CLI:

root@acc8494c-d206-481c-aaca-aeff62eab38b:/app/code# wp user list
+----+------------+---------------------+----------------------+---------------------+---------------+
| ID | user_login | display_name        | user_email           | user_registered     | roles         |
+----+------------+---------------------+----------------------+---------------------+---------------+
| 1  | admin      | admin               | admin@cloudron.local | 2022-03-18 22:22:58 | administrator |
| 2  | girish     | Girish Ramakrishnan | mail@girish.in       | 2022-03-18 22:24:27 | administrator |
+----+------------+---------------------+----------------------+---------------------+---------------+

girish

For good measure, I have tried both on WordPress Managed and WordPress Developer and I can't reproduce the problem.

d19dotca

Okay... this may be a bit more complicated than I thought initially. I had tested about 3 sites before in my testing, but I just went to do a different site and upgrade (throwing the plugin in debug mode before and logging in on old version and compare against new version, and the issue didn't occur. However I went to the site I could reproduce it before and sure enough it still is reproducible.

Here's a before & after log of the affected site:

Affected site

BEFORE:

Mar 19 17:27:15 [Sun Mar 20 00:27:15.727930 2022] [php7:notice] [pid 652] [client 207.216.93.172:46612] [AuthLDAP] User ‘<username>’ logging in, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:15 [Sun Mar 20 00:27:15.727985 2022] [php7:notice] [pid 652] [client 207.216.93.172:46612] [AuthLDAP] about to do LDAP authentication, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:15 [Sun Mar 20 00:27:15.727992 2022] [php7:notice] [pid 652] [client 207.216.93.172:46612] [AuthLDAP] connect to LDAP server, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:15 [Sun Mar 20 00:27:15.913285 2022] [php7:notice] [pid 652] [client 207.216.93.172:46612] [AuthLDAP] LDAP authentication successfull, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:15 [Sun Mar 20 00:27:15.922068 2022] [php7:notice] [pid 652] [client 207.216.93.172:46612] [AuthLDAP] Existing user, uid = 2, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:15 [Sun Mar 20 00:27:15.922741 2022] [php7:notice] [pid 652] [client 207.216.93.172:46612] [AuthLDAP] Existing user's role: administrator, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:15 [Sun Mar 20 00:27:15.923002 2022] [php7:notice] [pid 652] [client 207.216.93.172:46612] [AuthLDAP] The LDAP user has an entry in the WP-Database, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:15 [Sun Mar 20 00:27:15.948548 2022] [php7:notice] [pid 652] [client 207.216.93.172:46612] [AuthLDAP] user id = 2, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA

AFTER:

Mar 19 17:27:54 [Sun Mar 20 00:27:54.153389 2022] [php7:notice] [pid 652] [client 207.216.93.172:47482] [AuthLDAP] User ‘<username>’ logging in, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:54 [Sun Mar 20 00:27:54.153441 2022] [php7:notice] [pid 652] [client 207.216.93.172:47482] [AuthLDAP] about to do LDAP authentication, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:54 [Sun Mar 20 00:27:54.153454 2022] [php7:notice] [pid 652] [client 207.216.93.172:47482] [AuthLDAP] connect to LDAP server, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:54 [Sun Mar 20 00:27:54.309505 2022] [php7:notice] [pid 652] [client 207.216.93.172:47482] [AuthLDAP] LDAP authentication successfull, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:54 [Sun Mar 20 00:27:54.319895 2022] [php7:notice] [pid 652] [client 207.216.93.172:47482] [AuthLDAP] Existing user, uid = 2, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:54 [Sun Mar 20 00:27:54.320231 2022] [php7:notice] [pid 652] [client 207.216.93.172:47482] [AuthLDAP] Existing user's role: , referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:54 [Sun Mar 20 00:27:54.320249 2022] [php7:notice] [pid 652] [client 207.216.93.172:47482] [AuthLDAP] no role yet, set default role, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:54 [Sun Mar 20 00:27:54.320445 2022] [php7:notice] [pid 652] [client 207.216.93.172:47482] [AuthLDAP] The LDAP user has an entry in the WP-Database, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA
Mar 19 17:27:54 [Sun Mar 20 00:27:54.346697 2022] [php7:notice] [pid 652] [client 207.216.93.172:47482] [AuthLDAP] user id = 2, referer: https://<hostname>/wp-login.php?loggedout=true&wp_lang=en_CA

Notice that it found a role before the upgrade, and afterwards it said no role yet, set default role because it couldn't find the role.

I'm starting to suspect maybe this is more to do with something else in the database and could have possibly been caused by some leftover cruft from all the migrations I did previously from developer > managed > back to developer, lol. Just trying to investigate further but this is definitely a reprodcuible issue for some of my sites and apparently for others too like @fbartels (and I think @marcusquinn too?).

In my other site which I cannot reproduce the issue in, the logs are identical in both before and after.

girish

@d19dotca I can think of two things:

Have you checked any of the group sync options etc in the LDAP plugin by any chance ?
Can you see the output wp --format=json option get authLDAPOptions in the working and non-working instances and compare?

It should be a JSON like this:

    {
        "Enabled"       : true,
        "CachePW"       : false,
        "URI"           : "ldap://${CLOUDRON_LDAP_SERVER}:${CLOUDRON_LDAP_PORT}/${CLOUDRON_LDAP_USERS_BASE_DN}",
        "Filter"        : "(username=%s)",
        "NameAttr"      : "givenName",
        "SecName"       : "sn",
        "UidAttr"       : "username",
        "MailAttr"      : "mail",
        "WebAttr"       : "",
        "Debug"         : false,
        "DefaultRole"   : "${default_role}",
        "GroupEnable"   : false,
        "GroupOverUser" : false,
        "Version"       : 1
    }

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.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

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

Affected site

BEFORE:

AFTER: