Shibboleth vs mod_rewrite

[Brent Putman]

On 10/18/11 3:42 AM, Aaron Roots wrote:
>
> We have a particular directory that has the following rewrite rule in a
> .htaccess file: "RewriteRule ^.*$ index.php"
> - this code produces different results depending on the URL visited
>

This is pretty much the same issue that someone had over the summer
trying to get a Drupal-based app to work.  Drupal does the same thing
when the clean URL and alias options are used, i.e. "/app/a/b" gets
rewritten by mod_rewrite to be an effective request of
"/app/index.php?some-stuff", which is Drupal's controller endpoint that
processes all requests.

These threads might help you:

http://groups.google.com/group/shibboleth-users/browse_thread/thread/bb5d5f50e5931a5d/1b57b344a22d67bc

http://groups.google.com/group/shibboleth-users/browse_thread/thread/2004a827a9b0854c/18505e901b7e8924


As Scott already said, the issue is in whether the rewritten vs the
original request are inside or outside the space protected by the SP. 
The solution that worked for the person above is to protect the whole
area with a lazy Shib session and then either 1) protect some more
specific paths underneath there with a required Shib session or 2) do
something programatically in the app at the appropriate time to cause
the lazy session to be invoked.

>From the second thread, an example of #1 is:

<Location /drupal>
  AuthType shibboleth
  ShibRequestSetting requireSession 0
  require shibboleth
</Location>

<Location /drupal/cma/history>
  ShibRequestSetting requireSession 1
</Location>




> However this piece of code under mod_rewrite can not see variables set by
> Shibboleth ­ we have tracked this down to all the variables being changed
> into something like "REDIRECT_username" instead of just being "username".
> When we access the index.php directly it is working perfectly as expected
> in the default code path.



Yeah, the REDIRECT_ headers/variables are part of how mod_rewrite works
when it's doing internal subrequests.  You should be able to avoid that
nasty SetEnvIF workaround with a setup similar to the above.

> I haven't found much on what is going on that clears things up for me -
> does anyone know of a way to avoid the REDIRECT_ prefix occurring. I have
> seen some people that have both the REDIRECT_ and the normal coming
> through - it would be absolutely fine to have this occurring - but I can't
> quite see a way to do this either. 


I think the REDIRECT_ ones will be there if there's a subrequest, but
shouldn't hurt anything, they'll just be duplicates of the non-REDIRECT_
ones. 

> Or is it more drastic and we need to
> invest the time to avoid using mod_rewrite all together? 


It should work with mod_rewrite, you just have to figure out the quirks,
which is difficult given that this REDIRECT_ stuff and the internal
subrequest behavior doesn't seem to be well documented by mod_rewrite,
at least that I could ever find.