Error messages not always displaying at login form

[psignoret]

Needs more investigation, but basically, often error messages are not displaying in the login form (e.g. when not a member of the groups).

[atdr]

Hi @psignoret,

What's the best way to diagnose errors in the absence of any messages? I get redirected to /wp-login.php but not logged in.

[M-ine]

@Andre4s and @psignoret

From experience, there are 2 reasons why each time you try to login, you get redirected to wp-login.php

1. Make sure you have at least PHP7.
   From wp-login.php, when you click to login with O365, and upon succesfull authentication by microsoft, the url returned is quite long and completely ignored by PHP5 unless you make sure to increase the lenght for GET params. Because it is ignored, you get stuck to the wp-login.php page. With PHP5.x, to add support for long parameters with suhosin, add suhosin.get.max_value_length = <limit> in php.ini (source http://stackoverflow.com/questions/7724270/max-size-of-url-parameters-in-get)

2. You might need to force the reload of the ADDSSO openconfig configuration. In Settings.php (line 208), I don't know exactly why, but $openid_configuration was an empty string and the condition should have returned true in order to reload the configuration settings. Instead, the code was going staight to line 215 with $openid_configuration empty. This caused the authentication link not to be generated well, causing the redirect to wp-login. You can temporarily add at line 214 the code below and remove it after :

$openid_configuration = json_decode(
     self::get_remote_contents( $instance->openid_configuration_endpoint ),
     true // Return associative array
);
set_transient( 'aadsso_openid_configuration', $openid_configuration, 3600 );

Anyway in those 2 cases, you don't have any error messages displaying.

[atdr]

Edit: @cjh357 found what appears to be conflict with the VigilanTor plugin—everything works fine with it disabled.

[psignoret]

@andre4s: Thanks for the heads up, will look into it with #112 and see if we can play nicely together.

@M-ine: Both of these are interesting observations.

For 1, we can probably add an alert in the admin setting if the PHP value is too low. Alternatively (or in addition), we can change to the Form Post Response Mode, which will put the contents of the Authorization Response in POST, instead of GET, bypassing this URL length problem. Looking into this in #113.

For 2, the condition did not return true because we're using ===, which means the result must evaluate to FALSE and be a boolean. I'll have to look at this more carefully (to see what could have cause an empty string in the first place), and add some better validation of the returned contents (#114).

That said, if you ever need to force-reload the OpenID config, just add &aadsso_reload_openid_config=1 to the login page's URL, as described here: https://github.com/psignoret/aad-sso-wordpress#refreshing-the-openid-connect-configuration-cache

[M-ine]

@psignoret Thanks. Glad to be of use. Keep up the good work.