Daniel Westermann-Clark

I’ve added both @joraff and @shankie as committers per the other threads:

* https://www.ads-software.com/support/topic/maintained-fork/
* https://www.ads-software.com/support/topic/allow-access-to-fork-contributors-on-github/

I’ve added both @joraff and @shankie as committers.

https://www.ads-software.com/support/topic/allow-access-to-fork-contributors-on-github/

I’m more than happy to add new committers to the repository. @shankie, you’re now on the list.

Hi,

Thanks for the updates. I’ve added you as a committer for the www.ads-software.com plugin.

Did you check the server error log for details?

Interesting idea. I think your best option would be to:

1. Remove your lost password URL from requiring authentication by adjusting your .htaccess.
2. Set the 401 error handler to the lost password page in your .htaccess.

The hard part would be the first step. Depending on your current .htaccess it could be pretty difficult to get working given that the default lost password page also runs through wp-login.php. Might require a custom plugin to create a separate lost password page.

Give it try and let me know!

By the way, this feature request is being discussed here:

https://www.ads-software.com/support/topic/feature-request-network-setup

Resolving this topic.

In standard HTTP authentication, once your browser has remembered the credentials there’s no way for the server to force it to forget those credentials. This makes full “logout” pretty much impossible, and unfortunately this plugin can’t design around it.

Here’s some background information:

https://stackoverflow.com/a/449914

Hope this helps!

If you there’s no way to force the browser not to send the credentials (e.g., some authentication mechanisms support a separate logout mechanism) then the simplest option is to send them to a URL that doesn’t ask for the credentials. Depending on your configuration this may need to be on a separate domain name.

Hope this helps!

It sounds like you’re trying to overload browser behavior that would typically initiate basic authentication.

WordPress may be stripping the raw at sign (the plugin shouldn’t do anything to it). Was the at sign correctly displayed in the plugin settings page?

When you tried the URL-encoded version, did you try %40? Your post suggests you had an extra percent sign.

Any server which sets the REMOTE_USER variable in the environment (or something else) can be used. Normally this is provided via Apache’s authentication modules.

https://httpd.apache.org/docs/current/mod/mod_authn_core.html

Because of the various authentication schemes available, I can’t provide much guidance on what a successful or unsuccessful authentication response would look like. Instead try reading up on HTTP basic authentication for an example:

https://en.wikipedia.org/wiki/Basic_access_authentication

This is an oft-requested feature. I don’t have the time to add it myself but I’d help someone who submits a patch!

Finally made some progress. In my case I found that the server was not following WordPress’s rewrite rules as expected.

The behavior I found which led to the redirect loop can be seen using cURL from the command line:

$ curl -Ikv https://dev.example.com/wp-login.php
* About to connect() to dev.example.com port 80 (#0)
*   Trying 127.0.0.1... connected
* Connected to dev.example.com (127.0.0.1) port 80 (#0)
> HEAD /wp-login.php HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
> Host: dev.example.com
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
HTTP/1.1 302 Moved Temporarily
< Date: Tue, 28 May 2013 02:54:40 GMT
Date: Tue, 28 May 2013 02:54:40 GMT
< Server: Apache
Server: Apache
< WWW-Authenticate: Basic realm="Members Area"
WWW-Authenticate: Basic realm="Members Area"
< X-Pingback: https://dev.example.com/xmlrpc.php
X-Pingback: https://dev.example.com/xmlrpc.php
< Expires: Wed, 11 Jan 1984 05:00:00 GMT
Expires: Wed, 11 Jan 1984 05:00:00 GMT
< Cache-Control: no-cache, must-revalidate, max-age=0
Cache-Control: no-cache, must-revalidate, max-age=0
< Pragma: no-cache
Pragma: no-cache
< Location: https://dev.example.com/wp-login.php
Location: https://dev.example.com/wp-login.php
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
* no chunk, no close, no size. Assume close to signal end

<
* Closing connection #0

The 302 Moved Temporarily response (instead of 401 Unauthorized) suggested that the rewrite rules were not properly ending before the request was sent to WordPress. I confirmed this by disabling all rewrite rules and then selectively reenabling them until I got to the last one (where everything is sent to /index.php).

In my case I found from the Apache error log that the request was being internally rewritten to a different filename and thus bypassing the %{REQUEST_FILENAME} check:

[Mon May 27 19:44:30 2013] [error] [client 127.0.0.1] File does not exist: /home/me/dev.example.com/failed_auth.html

Adding the following to my .htaccess resolved the redirect loop:

RewriteCond %{REQUEST_URI} ^/(stats/|missing\.html|failed_auth\.html) [NC]
RewriteRule . - [L]

Your case may vary. I suggest inspecting the Apache error and rewrite logs for errors similar to the one above.

Your cURL should look like the following once you’ve pinned it down:

$ curl -Ikv https://dev.example.com/wp-login.php
* About to connect() to dev.example.com port 80 (#0)
*   Trying 127.0.0.1... connected
* Connected to dev.example.com (127.0.0.1) port 80 (#0)
> HEAD /wp-login.php HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
> Host: plugindev.danieltwc.com
> Accept: */*
>
< HTTP/1.1 401 Authorization Required
HTTP/1.1 401 Authorization Required
< Date: Tue, 28 May 2013 02:57:57 GMT
Date: Tue, 28 May 2013 02:57:57 GMT
< Server: Apache
Server: Apache
< WWW-Authenticate: Basic realm="Members Area"
WWW-Authenticate: Basic realm="Members Area"
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Content-Type: text/html; charset=iso-8859-1
Content-Type: text/html; charset=iso-8859-1
* no chunk, no close, no size. Assume close to signal end

<
* Closing connection #0

I’ve managed to reproduce the problem with WordPress 3.5.1. Working on a fix!

Hi there,

Can you check whether you’ve also added a .htaccess to your wp-admin directory?

It sounds like you’ve protected wp-login.php with Shibboleth but not wp-admin. This would mean that the login checks in wp-admin fail since REMOTE_USER is not present.