tbenyon

Hey @lucasbelini,

Can you confirm you’re on version 1.9.0 of the plugin?

There was a fix for this in the most recent version of the plugin. If you are definitely on this version. I’ll take a deeper look and see if I can replicate.

For that it’d be great to know which web browser you’re using. Most of my testing was done in Chrome.

Thanks,

Tom

Really appreciate you taking the time to write a review.

Good luck with your project 😊

I haven’t heard back so I’m assuming this is resolved.

If you have any further questions please don’t hesitate to get back in contact.

Kind regards,

Tom 🙂

I haven’t heard back so I’m assuming this is resolved.

If you have any further questions please don’t hesitate to get back in contact.

Kind regards,

Tom 🙂

Hey @kosmic7 and @tschmoyer,

I’ve just released version 1.9.0 of the plugin.

I believe this solves the issue 🙂

I would love to hear feedback to know if this is now resolved for you both.

For now, I will mark this as resolved but will change the status if you find further issues.

Thanks again for the beer support. Definitely increased speed of development 🙂

Tom 🙂

This is not currently supported.

I would be a little apprehensive to add this feature because this would dramatically decrease the security of a site.

I appreciate there are times when this would be deemed acceptable if no personal identifiable data could be viewed in the platform and the product owner was content with the hugely increased risk of people gaining access.

The other issue is that a password is not a unique identifier and WordPress requires a username to login.

You could make it so that everyone logs in as the same user but future issues with this depend on what functionality exist on the site regarding user control.

I guess that my current standing is that this is quite a unique use case and I would be uncomfortable making this a general setting as I would not want to encourage users to do this. Again, I do appreciate your use case may justify it.

At the moment I would say that if your use case does justify the drop in security and functionality that would come with it, you should get a developer to custom code this for you.

Always happy to discuss further, these are just my initial thoughts. 🙂

Interesting – this seems to be an issue with newer versions of WordPress.

I haven’t found the exact breaking point but I can make this work and break this by changing versions.

I’ll start looking into this.

Thanks for flagging 🙂

Hey @leifharmsen,

Just a small update.

I’ve got a working copy of your feature.

I’m hoping to make another few small improvements to the plugin so to avoid users having to update twice I aim to release tomorrow evening or Monday.

Hope this works for you.

I’ve written some psudocode in documentation for the plugin using your example.

Basically it’ll look like the following:
————————————–
– exlog_hook_filter_custom_should_exclude

This hook allows you to add custom logic to exclude users.

I provides you with all the data for the user that is stored in the external database users table.
If you return true from this function it will prevent the user logging in, and returning false will bypass this
exclusion.

For example, let’s say your external users table had a field called expiry which stored a date. In this example we
want to block users if they login after their expiry date.

Adding the following to your functions.php would achieve this:

function myExlogCustomExcluder($userData) {
    return strtotime($userData['expiry']) < strtotime('now');
}
add_filter('exlog_hook_filter_custom_should_exclude', 'myExlogCustomExcluder', 10, 1);

———————————

If you’re interested to know what the code change was you can see the current code change here:
https://github.com/tbenyon/wordpress_external_login_plugin/commit/c20cb3d2b4ed887e9ffef87c31d1763c9b8f54d1

Thanks,

Tom