Shibboleth vs mod_rewrite

[Aaron Roots]

Cheers for the articles and information

However unlike the drupal example - the shibboleth protection is on the
same directory as the real and rewritten path.

For example this is basically my setup:
   http://server/folder/ is the location being protected (ie <Location
/folder> etc)
   http://server/folder/index.php would be the real path
   http://server/folder/rewrite would be the rewrittable path that
rewrites to http://server/folder/index.php

Going directly to http://server/folder/index.php works as expected - going
to the http://server/folder/rewrite path - we don’t get the expected Env
vars - just the REDIRECT_ ones

So unless there is a way of double enabling shibboleth at a single
location - I don't think I can enable it again for index.php.

Aaron




On 19/10/11 2:27 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

>
>
>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/bb5d5
>f50e5931a5d/1b57b344a22d67bc
>
>http://groups.google.com/group/shibboleth-users/browse_thread/thread/2004a
>827a9b0854c/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.
>
> 
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net