raider1967

Hi Tom

Ok yes you are right, it’s just a warning as I forgot to set WP_DEBUG back to false again.

So yes the functionality flow is as you desribe now.

Thank you for your assistance with this and for a great plugin. I will sort out Review / Beer shortly.

regards
RAY

Hi Tom

I am aware of your setting that disables the local login, however as per previous posts this appears not to be working perhaps as it should.

To explain again,

As a test, I changed the user password in the external database and tried logging in again using the original password and then get an error as below

Undefined index: role in /wp-content/plugins/external-login/login/authenticate.php on line 13

If I use the new password, it logs in ok, assuming then that it is checking the external database.

How can I avoid this error above if the user changes their password and then forgets and tries logging in with the old password?

Of course, happy to leave a review / etc

Will sort that oput shortly.

thanks
RAY

Tom,

Is there a way to stop the user being created in the WP users table so that the plugin only ever authenticates from the external database ?

RAY

Hi Tom

Ok, yes I have now removed the $user = false line and that seems to rectify the issue completely.

Using your revised code without that line in it, I am able to log in ok from the external database and then if I log out, I can log in again successfully without error.

However, it still aeppears to be trying to use the WP user details even though I have disabled the local login in your plugin settings.

As a test, I changed the user password in the external database and tried logging in again using the original password and then get an error as below

Undefined index: role in /wp-content/plugins/external-login/login/authenticate.php on line 13

If I use the new password, it logs in ok, assuming then that it is checking the external database.

thanks
RAY

Tom

as a further follow up your revised code returns the following logs.

[18-Apr-2020 10:59:23 UTC] EXLOG START>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[18-Apr-2020 10:59:23 UTC] EXLOG resp >>>>
[18-Apr-2020 10:59:23 UTC] array (
‘username’ => ‘fredbloggs’,
‘password’ => ‘$2b$10$jZAJXrIUtoGZVQkGhCSdp.HyfWkgMsTEWFY5/Nwt2BaozFcYVRxlm’,
‘first_name’ => ‘FRED BLOGGS’,
‘last_name’ => ‘SEV’,
‘role’ => ‘none’,
’email’ => ‘[email protected]’,
‘exlog_authenticated’ => true,
)
[18-Apr-2020 10:59:23 UTC] EXLOG user >>>>
[18-Apr-2020 10:59:23 UTC] false
[18-Apr-2020 10:59:23 UTC] EXLOG HERE1
[18-Apr-2020 10:59:23 UTC] EXLOG END>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

I noticed in your revised code the following;

$user = false;
if ($user) {
$user = new WP_User($user->ID); // Attempt to load up the user with that ID
}

By setting $user to false, it will never then attempt to run the following code…. $user = new WP_User($user->ID); ??

thanks
RAY

Hi Tom

Thank you for your response which was all very helpful as an explanation. I am a PHP developer myself so do have a good understanding of what your code is doing.

First of all, the revised code that you sent me does partly correct the problem and the log in process works as expected on the first login. No errors are encountered and the user details are pushed into WP users table.

However, if I log out and then log in a second time I get the following error.

Undefined property: WP_Error::$ID in /wp-includes/class-wp-user.php on line 170

To answer some of your queries in your email, I have been running these tests on a brand new installation of WordPress using PHP version 7.3.16 – it maybe that it’s because of the newer version of PHP instead of an old version that is causing this issue – I know I have had problems with other projects switching up from PHP 7.1 to 7.3.

Yes, the following line of code is definitely returning false.

$user = $userobj->get_data_by(‘login’, $response[‘username’]); // Does not return a WP_User object ??

At this point in your code, would you expect the details of the user from the external database to have been copied into the WordPress database? It appears that the user within WordPress does not exist at this point in the timeline, however, when I check the WordPress users after the ID error has been encountered, the user has definitely been created and does exist correctly within WordPress. As yet I have been unable to discover what part of your code pushes the user details from the external database into the WordPress database.

During that first log in process, I am assuming that your code checks the external database for the user details, which it obviously finds because the authentication is coming back as ‘true’, copy of the log below

[18-Apr-2020 10:11:47 UTC] EXLOG response >>>>
[18-Apr-2020 10:11:47 UTC] array (
‘username’ => ‘fredbloggs’,
‘password’ => ‘$2b$10$jZAJXrIUtoGZVQkGhCSdp.HyfWkgMsTEWFY5/Nwt2BaozFcYVRxlm’,
‘first_name’ => ‘FRED BLOGGS’,
‘last_name’ => ‘SEV’,
‘role’ => ‘none’,
’email’ => ‘[email protected]’,
‘exlog_authenticated’ => true,
)

In your original code you have a comment that says…..

// External user exists, try to load the user info from the WordPress user table
$userobj = new WP_User();

What I don’t understand is if the external user exists, why would you then try to load the user from the WordPress database? I can only assume at this point in time that the user does not exist in WordPress, only in the external database

If I trace out $userobj I get the following which appears to be a blank WP user which would be correct based upon your $userobj = new WP_User();

[18-Apr-2020 10:11:47 UTC] EXLOG userobj >>>>
[18-Apr-2020 10:11:47 UTC] WP_User::__set_state(array(
‘data’ =>
(object) array(
),
‘ID’ => 0,
‘caps’ =>
array (
),
‘cap_key’ => NULL,
‘roles’ =>
array (
),
‘allcaps’ =>
array (
),
‘filter’ => NULL,
‘site_id’ => 0,
))

Once the process has been run that first time and the first ID error encountered, the user details are pushed over to WordPress so running the log in process a second time does then work because the code can then find the user within WordPress ok.

Another issue that is confusing things is that within your plugin settings within WordPress I have ‘Disabled Local Login’ which suggests that your code would only then check the external database for the user and not check the WP database. However, this appears not to function correctly as the WP database is still being checked within your authentication code. I am unable to locate any part of that authrnication process that says ‘If Disabled Local Login’ then dont check the WP database. Obviously I may be missing something that does that elsewhere but at the moment I cant see that my local WP database is being excluded.

Anyways, I hope the above may be of some use to you.

To clarify, the revised code you send me does fix my initial issue and enables me to log in using an external database which then pushes those user details to the WP users table. However, a subsequent login fails with the error mentioned earlier.

Again, if the ‘Disable Local Login’ is set as ON, should your process be checking the WordPress database – surely it would only check the external database and authenticate the user that way?

Will await further insight from you on this.

many thanks
RAY

Hi Tom

The log output on a test user is as below – it should be noted that the user info does get copied across to the WordPress Users table ok.

The role ‘none’ has been mapped to ‘Subscriber’.

All the other mappings are correct as far as I can tell.

regards
RAY

[14-Apr-2020 09:33:00 UTC] EXLOG START>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[14-Apr-2020 09:33:00 UTC] EXLOG resp >>>>
[14-Apr-2020 09:33:00 UTC] array (
‘username’ => ‘fredbloggs’,
‘password’ => ‘$2b$10$8/fDuw.Of7wL584GFrBoV.hEnUHmoXToJR.N3HSlD5/OFA0iyys.G’,
‘first_name’ => ‘FRED BLOGGS’,
‘last_name’ => ‘SEV’,
‘role’ => ‘none’,
’email’ => ‘[email protected]’,
‘exlog_authenticated’ => true,
)
[14-Apr-2020 09:33:00 UTC] EXLOG user >>>>
[14-Apr-2020 09:33:00 UTC] false
[14-Apr-2020 09:33:00 UTC] EXLOG END>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[14-Apr-2020 09:33:00 UTC] PHP Notice: Trying to get property ‘ID’ of non-object in /wp-content/plugins/external-login/login/authenticate.php on line 47
[14-Apr-2020 09:33:00 UTC] PHP Warning: Cannot modify header information – headers already sent by (output started at /wp-content/plugins/external-login/login/authenticate.php:47) in /wp-includes/pluggable.php on line 943
[14-Apr-2020 09:33:00 UTC] PHP Warning: Cannot modify header information – headers already sent by (output started at /homepages/11/d461060611/htdocs/clickandbuilds/HandPickedResources/wp-content/plugins/external-login/login/authenticate.php:47) in /wp-includes/pluggable.php on line 944
[14-Apr-2020 09:33:00 UTC] PHP Warning: Cannot modify header information – headers already sent by (output started at /wp-content/plugins/external-login/login/authenticate.php:47) in /wp-includes/pluggable.php on line 945

Yes the CSS Print method is set to External

I will await the update but as a developer myself, I do not understand how you could have released this version without testing it properly. From all the recent comments it is clear that version 3.5.2 has broken so many elements of the plugin, all of which result in failures of the websites. You need to take more care and test things fully before you release these updates.

It looks like version 3.5.2 has broken alot of different things and looking back at the history of posts, many of the updates regularly break things that were working ok previously – their testing processes are clearly not good enough.

Ok, I see the mapping area now and all working ok

thanks again for quick replies.

Just one further question.

When the plugin creates a user in the WP users table, the user is always a Subscriber and appears to ignore what is set in the ‘role’ field on the external table.

What value should I be using in the ‘role’ field to log someone in as an Administrator? I have tried using admin or administrator but the user always ends up as a Subscriber.

any thoughts?

Ok, it’s done. Appreciate your quick response.

thanks

Just to update you – I have now managed to successfully use the plugin using a wordpress installation on a different server.

So it may well be an issue with the original server or the firewall that was linked to it.

So all is ok now.

Ok will see what I can do on the PHP logs

Ok great. No rush, I’m really just trying to test the plugin for a future project.

It’s just a basic test WordPress installation with minimal other plugins at the moment.

Wait to hear from you when you can.

Thanks