Latest package with LDAP add-on

[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.