Latest package with LDAP add-on

[d19dotca]

I spun up a fresh WordPress Developer package this afternoon and chose the LDAP integration (rather than app-managed), set my admin group for it, and when I went to login I could not login, it fails and I can only log in with the automatically created admin user. Is this working for anyone else when setting a group for access with LDAP?

[Lonkle]

I'll probably test this over the next couple days; I'll let ya know if it works for me. ️

[Lonkle]

I just saw a new version was pushed for "Managed" and all LDAP users are "Editors" by default. Wonder if that's what you're running into, also wonder if that's configurable, cause I went them to be Admins by default in my Developer installation.

[d19dotca]

For me, I just deployed a fresh Developer WordPress package, and set it to use LDAP for a particular Cloudron group, then it finished deploying and I went to login with my Cloudron credentials (I am in the group I chose for it earlier), but it rejects my credentials on the wp-login.php page. So it's not an "Editors" role thing, it's just not letting me in outright.

[imc67]

@d19dotca strange, I migrated a unmanaged WP to a developer WP, (had to install manually the LDAP plugin) but after that it all worked immediately perfect!

Only thing is that the default setting of the plugin is that every LDAP user is author (you can change that), so you need to use the build in admin to change user rights of the LDAP users.

ps: the user name is without the @domain.tld (sounds stupid but all our users make the mistake between username and email address to login to ie. Roundcube)

[d19dotca]

@imc67 You had to install the plug-in? That doesn’t make sense though... LDAP option has to install that automatically. Maybe that’s the issue here then.

[d19dotca]

@imc67 Ah, you're right, it's the username. I was using my email on my Cloudron user account, not the Cloudron username itself. This is unfortunate though, I prefer to login with my email address whenever possible. Oddly enough, this has worked before (this is how I currently login to all of my Managed Cloudron app instances), so I wonder why this behaviour has changed recently.

[imc67]

@d19dotca said in Latest package with LDAP add-on:

@imc67 You had to install the plug-in? That doesn’t make sense though... LDAP option has to install that automatically. Maybe that’s the issue here then.

It was because I migrated a unmanaged WP to a developer WP

[girish]

@d19dotca I checked in 2 separate cloudrons and I can login immediately with my cloudron credentials. Cloudron uses get editor role, by default. You can change this as an admin though in the WP Admin Panel -> Settings -> authLdap -> Default Role.

Also, to double check what @imc67 said, are you logging in by username or email? Logging in by email is not supported.

[Lonkle]

@girish said in Latest package with LDAP add-on:

Logging in by email is not supported.

Is this a Cloudron LDAP limitation or just a Wordpress LDAP integration limitation? Because some web apps only have email and password for login

[girish]

@Lonk said in Latest package with LDAP add-on:

Is this a Cloudron LDAP limitation or just a Wordpress LDAP integration limitation? Because some web apps only have email and password for login

This is just for consistency across all apps (not just WP). The general flow we are going for is:

• You have an admin user. Admin user is important to exist in the case the LDAP is not working (for whatever reason like networking issue).
• Cloudron users can login with username into apps (not email). Only exception is webmail apps, that require email to login.
• The admin user can make a cloudron user an administrator inside the app. We want to delegate all role/permission management to the app itself. Cloudron will only do authentication and not authorization.

Note that we arrived at this flow from experience and trial/error. So, it's just being pragmatic.

[Lonkle]

@girish said in Latest package with LDAP add-on:

@Lonk said in Latest package with LDAP add-on:

Is this a Cloudron LDAP limitation or just a Wordpress LDAP integration limitation? Because some web apps only have email and password for login

This is just for consistency across all apps (not just WP). The general flow we are going for is:

• You have an admin user. Admin user is important to exist in the case the LDAP is not working (for whatever reason like networking issue).
• Cloudron users can login with username into apps (not email). Only exception is webmail apps, that require email to login.
• The admin user can make a cloudron user an administrator inside the app. We want to delegate all role/permission management to the app itself. Cloudron will only do authentication and not authorization.

Note that we arrived at this flow from experience and trial/error. So, it's just being pragmatic.

Thanks for such a detailed explanation of your thought pattern and flow. But it does make me wonder why email wouldn’t be included in making a user have the ability to login. Wordpress only user usernames for years but so many people installed a “login via email” that they gave in. So I was wondering why wouldn’t Cloudron’s LDAP consider both email or username as a valid “username” for LDAP purposes. Or is that a limitation of the LDAP protocol?

[girish]

@Lonk said in Latest package with LDAP add-on:

So I was wondering why wouldn’t Cloudron’s LDAP consider both email or username as a valid “username” for LDAP purposes.

On Cloudron, you can change the email (but not username). So, If you change the email, then try to login to the app, it may not work anymore because some apps store the email in their local database and to get them to change the email address, they have to "sync" with the cloudron directory correctly. This again depends on each app but for the end user it just causes confusion sometimes that they cannot login (especially since the browser remembered the email as their previous login...)

[d19dotca]

@girish Sorry I thought I already responded yesterday but apparently didn't save my comment. lol. So yeah, the issue was the format of the username, it was what @imc67 noted earlier.

What's strange to me though here is that this was never a restriction before, right? I currently log into all my Managed WordPress installs using my email for Cloudron LDAP. Was this restriction to username only recently added?

Any way to change back the behaviour to email too? I know you said this is from a lot of learning and experience with trial and error, but for WordPress the login page says "username or email address", so I would expect us to login with either, not just one, otherwise the login page isn't exactly accurate at that point.

[d19dotca]

@girish said in Latest package with LDAP add-on:

If you change the email, then try to login to the app, it may not work anymore because some apps store the email in their local database and to get them to change the email address, they have to "sync" with the cloudron directory correctly.

Is there perhaps a way to make it so that when a Cloudron user logs into WordPress that their email is not-configurable and therefore must match what is in Cloudron LDAP? I'm thinking similar to how the website URL and such in WP Settings is not configurable through the GUI because it's set in the lower level files.

[girish]

@d19dotca said in Latest package with LDAP add-on:

Is there perhaps a way to make it so that when a Cloudron user logs into WordPress that their email is not-configurable and therefore must match what is in Cloudron LDAP?

The WP LDAP plugin we use does not allow users to lock the email address. It doesn't support syncing either. I do note that there is another plugin which supports syncing - https://wordpress.org/plugins/ldap-login-for-intranet-sites/ which wasn't around before.

Also, correct, I recently removed the email login to make it consistent with non-WP apps.

[Lonkle]

@girish said in Latest package with LDAP add-on:

@d19dotca said in Latest package with LDAP add-on:

Is there perhaps a way to make it so that when a Cloudron user logs into WordPress that their email is not-configurable and therefore must match what is in Cloudron LDAP?

The WP LDAP plugin we use does not allow users to lock the email address. It doesn't support syncing either. I do note that there is another plugin which supports syncing - https://wordpress.org/plugins/ldap-login-for-intranet-sites/ which wasn't around before.

Also, correct, I recently removed the email login to make it consistent with non-WP apps.

If I put in the work for this would you re-consider email attribute being considered in your Cloudron LDAP system, if only for Wordpress' sake?

Tbh, it was an uphill battle getting them to allow us to use our email addresses in the WP Core (almost everyone uses a plugin to do it previous to it being in core). Anyway, if syncing is your only issue, and if I was able to rectify that issue somehow, would this be a consideration for you to re-allow?

[d19dotca]

@girish Thank you for confirming. Glad to know I wasn't going completely crazy, haha. I'd love to be able to login with username and email, not limited to just one. I'd love to see that decision to only allow usernames be reconsidered, if possible.

[Lonkle]

@d19dotca said in Latest package with LDAP add-on:

@girish Thank you for confirming. Glad to know I wasn't going completely crazy, haha. I'd love to be able to login with username and email, not limited to just one. I'd love to see that decision to only allow usernames be reconsidered, if possible.

I'm of the same mind, if only because I'm such a heavy Wordpress user and we all were so excited for email logins. So, if you're willing to switch stances, I'll cover whatever you need to happen on the Wordpress side (such as writing the code to sync user emails).

[d19dotca]

Another way of looking at it too (maybe I'm overthinking this though)... if the application itself states it can be "username or email" as WordPress login page does, then theoretically I should be able to login with both (either of them) as that is what the app allows. And if I can only use one, then I would view this new restriction to username-only as an artificial Cloudron limitation which wouldn't be made clear to people using the app from the app's login page. This could easily cause confusion with users who are expecting to login with their email because that's what it says they can do, but then we'd have to explain to them as admins that they can't actually do what the login page says.

In other words... if the app states I can use username or email, then I should not be restricted to only one, IMO.

[marcusquinn]

@d19dotca bain of a Sys Admins life logins eh!

Would love to see a Cloudron oAuth-type solution. I need some sponsored apps alive in the App Store first @Lonk , then maybe we can assist with that.

[girish]

The "username or email" text is present in login screen of many apps - wekan, rocket.chat. gitlab, etc. The issue is that many of the apps do not sync the "email" field when they are changed on the cloudron side. Which means suddenly login won't work. The email login comes from the past where we didn't pay attention to these issues (just like we didn't pay attention to how many apps support OAuth and blindly implemented it).

I am not disagreeing with you guys here I see both sides of it and one has to compromise somewhere. Maybe we can to spend time to go through all the apps and make email login work. Just having it work with 1 or 2 apps is causing confusion (how do you say it works in app x,y,z but not in others?).

[d19dotca]

@girish said in Latest package with LDAP add-on:

Just having it work with 1 or 2 apps is causing confusion

Totally agreed. We should be consistent, for sure. I tried recently as a result of this to deploy Matomo for a test instance, and could login fine with the email still, so even at the "username-only" mantra it isn't consistent either.

[Lonkle]

@girish said in Latest package with LDAP add-on:

Maybe we can to spend time to go through all the apps and make email login work.

That works for me. We can revisit this in 2021 when we believe we can dedicate time to all apps to add the email field. LDAP is a simple enough protocol so it shouldn't be too hard but def a 2021 kinda thing.

Thanks for the insight, as always girish!

[girish]

Yeah, I want to prioritize making the LDAP addon "dynamic" before spending time on this email login. i.e you can choose at whatever you want at install time. But later, you can always turn LDAP on/off dynamically.

[Lonkle]

@marcusquinn said in Latest package with LDAP add-on:

. I need some sponsored apps alive in the App Store first @Lonk , then maybe we can assist with that.

I had to finish my full app following all of Cloudron practices. So I underestimated how much time that was going to take. I made the last update to it today and it's ready for the store. So, now, I feel ready packing more now that I've finished mine completely.

[Lonkle]

@girish said in Latest package with LDAP add-on:

Yeah, I want to prioritize making the LDAP addon "dynamic" before spending time on this email login. i.e you can choose at whatever you want at install time. But later, you can always turn LDAP on/off dynamically.

Yes, definitely really like that idea, gonna have to dive into the DB for that, but it's doable and sounds like more current users would LDAP if they could turn it on after it gets supported (the situation Wodpress Developer is in rn).

[d19dotca]

@girish Quick question (hopefully), slightly related but I can file a new one if you'd like: Now that the package has LDAP support, I'm starting migrating my sites (once again haha) from Managed to the updated Developer package of WordPress, and while it's mostly been super easy so far, I'm running into a strange issue I noticed tonight where I'm still able to login with the email despite it not being set in the AuthLDAP plugin. I even double-checked and the configuration of the AuthLDAP plugin and see only username is listed, not mail.

One caveat here though is this source site I'm migrating is actually from an older Unmanaged one, not Managed. So maybe that's part of it? I don't know why that'd make a difference though. But I'm really struggling to get it to behave the way it should if I was starting this from scratch with the new Developer packaged one. Any ideas? Or maybe @Lonk will know this one? Maybe some sort of AuthLDAP / LDAP cache? Restarting the app doesn't seem to clear it though.

[girish]

@d19dotca That is indeed interesting behavior. Maybe it's coming from built-in WP behavior to check username or email. I am not sure how that would work, but clearly it does. I have to investigate later to tell you the reason.

[Lonkle]

@d19dotca There's no cache, it's pretty straightforward. Hmm, what happens if you disable the LDAP plugin and try to login with the same credentials (email) to see if it lets you in? I wanna check if this is LDAP related or something within Wordpress and that'll let me know it's the plugin.

[d19dotca]

@Lonk I'll test this out again and let ya know soon.

---

UPDATE: I just tried and see that it works fine now. Initially it didn't after migration even during this latest test, however I updated the field again to be just username and not mail, and suddenly now it worked as expected where it'll only accept the username and not email address. No idea why that didn't work when I did it yesterday, but I either overlooked something before or maybe it didn't save properly, I dunno. Seems to be okay now though.

[Lonkle]

@d19dotca Glad you got it working as expected. I still want to appeal to the devs to allow email in LDAP, but we certainly don't want that to work when it shouldn't be working. Hopefully we'll get to add real LDAP email support to Wordpress (Developer) one day. ️

[d19dotca]

@Lonk Actually now I'm super confused. lol. I thought it was fine, but now I'm seeing it letting me login again with the old password, so I went to remove it, and I found out I can actually still sign in with both the old password (since it was in the database from the old managed wordpress) and even the email address. No idea why this suddenly changed again. Maybe my brain is fried, lol. I'm going to try again now and disable the AuthLDAP plugin entirely and see what's up.

[d19dotca]

@Lonk Okay yes, I can confirm that it works even with the AuthLDAP plugin disabled, when I use my old credentials (i.e email address + password). This kind of makes sense too since it was a Managed WordPress instance so everything was local anyways and not using LDAP. But what makes no sense to me is if I've removed the password from the wp_users table for my user, why it still lets me in. Any ideas?

[Lonkle]

@d19dotca That's really odd, you literally removed the password hash from the DB in your personal user and you still can login with the LDAP plugin disabled?

The only thing I can say for now is to make sure the password hash you deleted matches your actual user_id. Like, just a little double check there. Because that is super bizarre.

[d19dotca]

@Lonk said in Latest package with LDAP add-on:

you literally removed the password hash from the DB in your personal user and you still can login with the LDAP plugin disabled?

Yeah, super strange right? Never seen this behaviour before. It shouldn't be possible.

There's nothing in the user_pass box, and I'm the only user account in this particular website so I couldn't have messed up which user account, haha. There's only one row in that table.

[Lonkle]

@d19dotca How about this - delete the plugin. Very rarely (but totally is a thing) there are plug-in...remnants. And also, you tried incorrect passwords and incorrect usernames right? Hmm, maybe try another user on the Cloudron LDAP that isn’t you before you fully delete the plug-in to see if it’s actually still using LDAP somehow.

[d19dotca]

@Lonk Yeah I did, the incorrect usernames and passwords behave as expected -- they won't login. I've completely deleted the plugin and it still loads up the old credentials. It's definitely not doing LDAP because the password from before when it was Managed (since it didn't have LDAP) is completely different password. I have no idea how this is working this way. lol.

[Lonkle]

@d19dotca One last idea, check wp-config.php, is it pointing to the database name you edited?

[d19dotca]

@Lonk Good idea! Just checked though and yes indeed it's pointing to the right database, confirmed by comparing the value in wp-config with the value of show databases; in MySQL terminal.

[Lonkle]

@d19dotca Next idea then, weird caching issue. Can you try it in an incognito window?

[d19dotca]

@Lonk Ah I did that before, but just tried again in case and still no-dice, it still loads fine with old credentials. I've never run into this issue before. I've seen it the opposite where two passwords would work (i.e. the one from managed and then the one with LDAP on Managed when I went from Unmanaged to Managed once), but that was solved by simply removing the password from the database. This time it's almost the opposite where it'll take the old credentials, not the new ones (if AuthLDAP is disabled anyways which is expected), even though the old credentials don't appear to be stored anywhere.

[Lonkle]

@d19dotca Alright, throwing spaghetti at the wall now. Clone the installation and try to login in THAT installation.

[d19dotca]

@Lonk haha, fair enough, I'll try that too.

[d19dotca]

@Lonk Same thing on the cloned app I'm completely out of ideas. I can't explain this, haha.

[d19dotca]

@Lonk Btw I don’t think I said it but... thank you! I appreciate the time you’ve spent trying to troubleshoot it.

[d19dotca]

@Lonk Okay I think I may have fixed it, but I'm not certain I trust it. So what I did was generate a new password in the database directly with MD5, then saved that. Then tried and couldn't login again via a private window (so I could still remain logged in elsewhere), then I removed the password again from the database, wondering if that'd let me login with the old password still again, and now it seems to be working as expected when there's no password in there that it will forbid that user from logging in locally. So it seems good now... but not sure how much I trust this, lol. Will keep testing, but I think this may be finally working the way I expect it to, via LDAP Auth only.

[Lonkle]

@d19dotca Wordpress is my favorite and Cloudron is my new development passion so I’m happy to troubleshoot WP stuff to find edge cases that Cloudron may need to account for.

I am very for making WP the best it can be on Cloudron. ️

I’m happy I’ve been able to help troubleshoot with you!