Requests rewritten using mod_rewrite get blocked with error "Request is a replay"

[nscheer]

When using mod_rewrite to redirect all incoming requests to a single resource (i.e. index.php), the requests get blocked with the following error message:

[Tue Dec 06 10:26:20.901557 2016] [auth_gssapi:error] [pid 7551:tid 140581023987456] [client 172.16.37.37:49833] gss_accept_sec_context() failed: [Unspecified GSS failure. Minor code may provide more information (Request is a replay)]

The test system is a CentOS 7 x64 (CentOS Linux release 7.2.1511) using apache 2.4.6 event mpm and version 1.4.1 of mod_auth_gssapi.

The vhost configuration is as follows:

<VirtualHost 172.16.37.101:*>
    ServerName myserver.local

    DocumentRoot /var/www/htdocs
    
    AddHandler fcgid-script .php
    
    <Directory /var/www>
        Options FollowSymlinks ExecCGI
        FCGIWrapper /var/www/fcgi/php-fcgi-wrapper .php
        
        Require all granted
    </Directory>

    <Location />
        AuthType GSSAPI
        AuthName "SSO-Login"
        
        GssapiLocalName on
        GssapiCredStore keytab:/var/www/dummy.keytab
        
        Require valid-user
        
        RewriteEngine on
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule . /index.php [L]
    </Location>
</VirtualHost>

Both, the gssapi configuration and the rewrite rules work fine for themselves but not in conjunction.

[nscheer]

Possible workaround: Since apache 2.2.16 the directive "FallbackResource" can be used to achieve this simple "redirect requests to non existing resources" behaviour, e.g.:

<Location />
        AuthType GSSAPI
        AuthName "SSO-Login"
        
        GssapiLocalName on
        GssapiCredStore keytab:/var/www/dummy.keytab
        
        Require valid-user

        FallbackResource index.php
    </Location>
</VirtualHost>

This configuration works fine in combination with mod_auth_gssapi.

Of course, there are more complex scenarios where mod_rewrite can't be avoided.

[iboukris]

This is a bit strange since we do have some logic to implicitly handle subrequests.
I was able to reproduce however, I'll try to look further.

[iboukris]

Ok, I think I kinda figured it out, the problem seems to be with internal-redirects, which are a special case of sub-requests that do not have req->main.
The call to ap_is_initial_req() checks for both subrequests and internal-redirects (req->main, and req->prev), but we explicitly check for req->main (since c1b6fca) so in the case of internal-redirects (no req->main, but with req->prev) we miss the implicit handling logic.

I've managed to get it to work correctly by borrowing some logic from mod_auth_digest, to handle both flows. It isn't ready as I'm not clear enough on some details, but it works: modauthgssapi/mod_auth_gssapi@2202cfd

@scopev24 would be nice if you can check this patch in your env meanwhile.

[simo5]

@Frenche please turn into pull request 👍

[nscheer]

@Frenche tried your patch - works fine so far!

[iboukris]

@scopev24 thanks for testing, feel free to test the new version too :)

[simo5]

#119 has been pushed so the issue is solved.