TKTAuthBadIPURL - Getting the new IP

[Claude]

Hello everyone!

I've been an auth_pubtkt user since around 2008 and it has always worked extremely well for us. Lately, I've been using version 0.6a on production servers without a glitch.

We are in the process of upgrading our servers, OS, etc. and I am looking at implementing the latest auth_pubtkt version (0.8).

There is one new feature that is of particular interest to us: TKTAuthBadIPURL introduced in version 0.7 and contributed by John Wittkoski. I haven't found any documentation on this new feature.

Our cookie is generated on an https connection and includes the client IP (cip), but the cookie may later be used on regular http (non secure) connections to our different sites. Sometimes - rarely but it happened a couple of times - one of our students in a remote area will be on a proxy for regular http connections and will therefore be asked to log in again because of the different IP then the one stored in cip and because https connections do not usually go through the proxy. The problem we face is that we don't know the IP of the proxy that triggered the redirect to the login page and therefore cannot generate a new cookie using the proxy's IP. I've been doing tests
and tried to pass the "bad" IP in the Apache directive "TKTAuthBadIPURL https://login.oursite.com/login.php?badip=%{REMOTE_ADDR}", but it does not work; %{REMOTE_ADDR} is passed as text in the URL.

Would there be an easy way to pass the current client IP through the TKTAuthBadIPURL directive? We are still on Apache 2.2.22 but may switch to Apache 2.4.

Thank you in advance!

Claude

[Manuel Kasper]

On 10.02.2015, at 18:37, Claude <claude...@gmail.com> wrote:

> Our cookie is generated on an https connection and includes the client IP (cip), but the cookie may later be used on regular http (non secure) connections to our different sites.

Forgive me for pointing out the obvious, but it seems that in 2015 nobody should be using regular HTTP anymore when transferring any kind of authentication token or accessing anything but public information ;)

> I've been doing tests and tried to pass the "bad" IP in the Apache directive "TKTAuthBadIPURL https://login.oursite.com/login.php?badip=%{REMOTE_ADDR}", but it does not work; %{REMOTE_ADDR} is passed as text in the URL.

The TKTAuthBadIPURL directive doesn't support placeholders.

> Would there be an easy way to pass the current client IP through the TKTAuthBadIPURL directive?

Only one comes to my mind right now: you could use it to redirect to an HTTP URL (PHP script or whatever) on the same server, then grab the client's (or rather proxy's) IP address and issue a redirect to the HTTPS login page with the IP as a GET parameter.

- Manuel

[Claude]

On Tuesday, February 10, 2015 at 4:24:55 PM UTC-5, Manuel Kasper wrote:

On 10.02.2015, at 18:37, Claude <claude...@gmail.com> wrote:

> Our cookie is generated on an https connection and includes the client IP (cip), but the cookie may later be used on regular http (non secure) connections to our different sites.

Forgive me for pointing out the obvious, but it seems that in 2015 nobody should be using regular HTTP anymore when transferring any kind of authentication token or accessing anything but public information ;)

 
Hello Manuel!

We're moving into that direction, but in the meantime.

> I've been doing tests and tried to pass the "bad" IP in the Apache directive "TKTAuthBadIPURL https://login.oursite.com/login.php?badip=%{REMOTE_ADDR}", but it does not work; %{REMOTE_ADDR} is passed as text in the URL.

The TKTAuthBadIPURL directive doesn't support placeholders.

> Would there be an easy way to pass the current client IP through the TKTAuthBadIPURL directive?

Only one comes to my mind right now: you could use it to redirect to an HTTP URL (PHP script or whatever) on the same server, then grab the client's (or rather proxy's) IP address and issue a redirect to the HTTPS login page with the IP as a GET parameter.

- Manuel

I'm working on this, but I would have liked a more "elegant" (without redirects) way to do it.

Thank you for your quick reply!

Claude

[John Wittkoski]

Claude,

I ran into the same issue.

I have a fix for it that I've been using but I hadn't sent a PR. I will do that this weekend.

    --John

--

---
You received this message because you are subscribed to the Google Groups "mod_auth_pubtkt users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod_auth_pubtkt-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Claude]

Thank you very much John!!

I have the double redirect working (there is some delay/latency, of course) but would most probably prefer your solution.

I will be away all next week but will check back in about 10 days.

Thanks again!

Claude

*****************