unable to authenticate

Okay looks like 2.1.3 is not working with wpMu subdomain setup
I have only tested with wpMu subdomain setup

I deleted 2.1.3 and added back 2.0.2 and was back logging into the correct apps for each 5 providers

I have 3 apps on 5 providers (f-t-G-w-l) all are working with the accept ion of twitter. One theme keeps adding new users (rich_1 – rich_2 – rich _3 etcetera with the same credentials logging in since it is not happening in other themes it must be the theme.
What was happening in 2.1.3 with my set up was..

On authentication the login was going to https://main_domain/subdomain/etcetera and the file could not be found since there is no subdomain folder named by that domain. So it is not resolving within the code for the virtual directory in wpmu it was looking for the physical subdirectory path. It is placing the actual subdomain name as a physical path. In 2.1.3 the correct domain comes up that is associated in wp with the subdomain and resolves to the correct name resolve for the subdomain giving the subdomain path as https://resolved_subdomain/etcetera.
I will submit a support ticket to the developers and add supporting documentation. I really like this plugin hope it can be resolved for wpmu domain mode
Thanks
Rich

Correction

In 2.0.2 the correct domain comes up that is associated in wp with the subdomain and resolves to the correct name resolve for the subdomain giving the subdomain path as https://resolved_subdomain/etcetera.

I did some in-depth digging and I think I have found the source of this bug. As far as I can tell this bug was present in WordPress Social Login version 2.0.3 as well as 2.1.3, and I believe it would prevent any WordPress Multisite from working properly with WordPress Social Login.

The source of the problem is within the wsl_get_user_by_meta function in wordpress-social-login/includes/services/wsl.user.data.php:

In the line…

$sql = “SELECT user_id FROM {$wpdb->prefix}usermeta WHERE meta_key = ‘%s’ AND meta_value = ‘%s'”;

$wpdb->prefix should be $wpdb->base_prefix or $wpdb->usermeta.

For a non-multisite WP instance, $wpdb->prefix and $wpdb->base_prefix are interchangeable, but for a wpMu setup $wpdb->prefix returns the prefix for the blog-specific tables (e.g. “wp_3_”) whereas $wpdb->base_prefix returns the table prefix for the WP instance (e.g. “wp_”). And $wpdb->usermeta returns the name of the usermeta table (e.g. “wp_usermeta”).

I actually think most, if not all, of the 26 occurrences of $wpdb->prefix in the plugin need to be corrected.

I look forward for these corrections and I am more than happy to assist in testing it on my multisite networks.

Hi!
When trying to login with Facebook i always gett his error message and can’t login: Bouncer says no.
What is wrong?

Thanks

Arturo,

Bouncer for wsl is like a bouncer at a night club wont let you in unless your have the right info in this case the key set.
Make sure you set bouncer to yes accept new registrations and yes allow authentication. If still a problem would have to be with settings in facebook application are correct especially the link

https://hybridauth.sourceforge.net/wsl/bouncer.html

Rich

Thanks Jind

Going to test here next day or two working on wp worldwide bot attach issue that is slamming host providers around the world on wp installs it’s a brute force. I am implementing cloud flare. Heads up you can get a free account on cloud flare route your traffic through their network protection and caching they are providing free wp brute force protection because of this bot to even free memberships. Its working great and the speed is fantastic extremely easy to implement change of cname record on the fly you can shut it off and on any time in your account have to wait for it to probligate

Denis have you tested jind fix yet? – if so what are your results.

Thanks
rich