When used with mod_auth_gssapi, the module may not be usable and requires Negotiate at every request

Problem

When using this module with the Apache module mod_auth_gssapi (which facilitates Kerberos authentication, among other things), in some setups and configurations, it may not be possible to fully use the site. Furthermore, mod_auth_gssapi authentication using Negotiate has to be performed at every request to the Drupal site. This is caused by the module logging out the current user when REMOTE_USER is empty - but to set REMOTE_USER and thus prevent the user from being logged out, mod_auth_gssapi authentication must be performed.

Explanation:

Kerberos authentication using mod_auth_gssapi facilitates Negotiate method, which is one of HTTP Authentication schemes. How this works is fairly good described for example in
https://www.adelton.com/docs/apache/optional-kerberos-authentication - see the second diagram for a comprehensive scheme or
https://tools.ietf.org/html/rfc4559.

The problem is that, in some setups and configurations (I don't know which, as I failed to reproduce the problem later) this mechanism interferes with all requests of the type other than GET - mainly POST and AJAX. In this case, only two scenarios can follow:

1. mod_auth_gssapi can be configured to perform authentication at all pages of a Drupal site - this results in REMOTE_USER being set on every page, as it is when using HTTP Basic or Digest authentication. It will be possible to log in to the site - also as admin - but he will not be able to change anything - configuration changes or operations with content cannot be performed. See attached screenshots 1-5 (note that I changed the configuration of mod_auth_gssapi between screenshots 2 and 3, hence the different, but still dysfunctional behaviour). This is therefore not applicable in this case.
2. mod_auth_gssapi can be also configured to perform authentication only at one page - ideally the dedicated login page, for example /drupal7/?q=loginGSSAPI or /drupal7/loginGSSAPI. The problem is that as Webserver authentication logs out users upon empty REMOTE_USER, users are logged out upon leaving the login page. This configuration is therefore never practically applicable when using this module.

Therefore the only case when this module is usable with mod_auth_gssapi is when both:

• mod_auth_gssapi is configured to perform authentication at all pages of a Drupal site and
• the setup, configuration and possibly other factors (as I wrote above, I don't know what influences this) does not cause Negotiate authentication mechanism to interfere with non-GET HTTP requests

All in all, this means that not only getting mod_auth_gssapi authentication to work may be problematic, but also inability to avoid performing mod_auth_gssapi authentication through Negotiate at every request to the Drupal site is a considerable waste of system resources, network bandwidth and (potentially) time.

Proposed solution

Logging out the user is still desirable in the case that REMOTE_USER has changed and is nonempty, but it must not be happening when the REMOTE_USER is empty. However, when using those ways of authentication that Webserver authentication was designed for so far, it is probably desirable to preserve the current behaviour.

Therefore I suggest creating a new configuration variable webserver_auth_logout_empty_remote_user, which will determine whether the current user (session) will be logged out or not, when the REMOTE_USER is empty.
IMPORTANT: What about its default value? For certainty of this having effect, this configuration variable should be FALSE by default (meaning new behaviour). That is how it is set in the patch appended. It is still possible to set it to TRUE for users of other authentication methods than mod_auth_gssapi, but it may not be possible for users of mod_auth_gssapi authentication to set it to FALSE. Of course, feedback and discussion on this is welcomed and if this should cause problems, I will change the default value to TRUE.

User interface changes

A new option will be available in the configuration page of the module - when expanding the 'Advanced settings' section, the 'Logout the current user if the authname is empty' setting regulates the functionality introduced by this patch.

Files

I have tested this solution and it worked. See file patch1.patch - note that this file is generated from GitHub repository.