There is no redirect 'back'

[om]

Hi,

I am implementing SSO using mod_auth_pubtkt and running into a
problem. For some reason there is no redirect back to the protected
url. The test php script shows that I logged in as a testuser and the
uri seems to be correctly encoded e.g.
http://example.com/tkt/login?back=http%3a%2f%2fexample.com%2fprotected%2f.
I wonder what could be going on that prevents the actual client
redirect to the 'protected' directory after the login. I'm running the
debian stable apache 2.2.16.

Here is the config:

<Directory "/var/www/protected">
Options +FollowSymLinks
AllowOverride AuthConfig FileInfo Indexes Limit
Options=All,MultiViews
AuthType mod_auth_pubtkt
TKTAuthLoginURL "http://example.com/tkt/login"
TKTAuthTimeoutURL "http://example.com/tkt/login?
timeout=1"
TKTAuthUnauthURL "http://example.com/tkt/login?
unauth=1"
require valid-user
TKTAuthDebug "3"
</Directory>


Thanks,

Alex

[Manuel Kasper]

On 27.08.2011, at 00:43, om wrote:

> I am implementing SSO using mod_auth_pubtkt and running into a
> problem. For some reason there is no redirect back to the protected
> url. The test php script shows that I logged in as a testuser and the
> uri seems to be correctly encoded e.g.
> http://example.com/tkt/login?back=http%3a%2f%2fexample.com%2fprotected%2f.
> I wonder what could be going on that prevents the actual client
> redirect to the 'protected' directory after the login. I'm running the
> debian stable apache 2.2.16.

That's odd - the redirect (after generating the ticket/setting the cookie) in the example PHP login page that comes with the distribution is really simple; not much that could go wrong there.

What happens if you manually access the protected directory after login - does it work or do you get redirected back to the login page? If it's the latter, then mod_auth_pubtkt didn't like the ticket for some reason. You could set "TKTAuthDebug 1" and "LogLevel debug" in your Apache config to find out why.

- Manuel

[Oleksandr Moskalenko]

The ticket is generated correctly. If I go to the protected page manually I am allowed in and the REMOTE_USER header is set correctly. I also wrote a simple php script that does nothing but redirect using header(Location: ….) from the auth area to the protected area and it works fine. So, I guess the example php script is indeed the culprit, though I will probably have to dissect it completely to find out what's wrong.

Regards,

Alex