Doh, there is a referer_regex ACL type, but I don't see that helping here
anyways.
1)Browser wants to visit website.com and hits the proxy.
2)Request gets redirected to the signup_disclaimer.htm website.
3)User signs up and/or logs in.
4)The page that verifies the username/password then redirects to the
originally requested site with the login information stored in the correct
header. (via the proxy)
5) the proxy sees the refering site and proxies the request.
A better 5) would be squid sees it has an already authenticated request so
passes it through. Otherwise the user would have to log in, on the
disclaimer page, every time they clicked a link. Open a new window/session
though and then the user would have to log in again.
Hopefully my ramblings help Rick out. I see a loop happening though. If
proxy_auth is required, the user gets the pop up window, even if they don't
have an account yet. Once they visit the login page, that page should be
able to write/create the http_proxy_authorization header.
I don't see how to redirect the user if they are not auth'd yet without
redirecting them when they are auth'd later so it looks like they are stuck
with the logon prompt and only get to the disclaimer/login page when they
fail to authenticate.
Chris Perreault
-----Original Message-----
From: Chris Perreault
Sent: Wednesday, July 21, 2004 10:15 AM
To: squid-users@squid-cache.org
Subject: RE: [squid-users] Re: Implementation issues
We may turn into such a sponser. In reverse proxy mode we are looking for a
solution where we need to authenticate users as far out in the DMZ as
possible. Using ldap via basic auth results in some difficulty in reaching
some of the content on various back end webservers which also uses basic
auth. Over the next few days we'll determine the best solution, which may be
having users redirected to a logon webpage, use a form based authentication
that saves the ip, then passes the username down in a header to the back end
webservers, thus allowing some of those servers to match the header username
with a username in a profile database for portal type content delivery while
still allowing basic auth type apps to do their own authentication.
If squid knew the referring IP address (the webserver that has the
authenticating form on it that after submital send the browser back to
Squid) then all users could be directed to the logon page, and after hitting
submit go back to the proxy which would allow that referring IP to get
proxied info from the web. Spoof the IP though and you get through without
authenticating. Figuring that IP out might be difficult for a end user
though.
Chris Perreault
-----Original Message-----
From: Adam Aube [mailto:aaube01@baker.edu]
Sent: Tuesday, July 20, 2004 8:15 PM
To: squid-users@squid-cache.org
Subject: [squid-users] Re: Implementation issues
Henrik Nordstrom wrote:
> On Wed, 14 Jul 2004, Rick Whitley wrote:
>
>> I was setting up a proxy server to do the authentication and
>> cacheing, but have learned from the list that it is not going to
>> behave the way I expected. Users should only see the initial page
>> once. I seem to be out in left field as to how to implement this. Any
>> suggestions?
>
> In theory it is possible to implement very close to what you want with
> Squid & authentication, but so far no one has been willing to actively
> sponsor such development.
>
> It is also possible to use a small proxy.pac script implementing the
> "startup splash" screen.
Something like this might be a good starting point:
http://www.squid-cache.org/mail-archive/squid-users/200404/0793.html
Adam
Received on Wed Jul 21 2004 - 13:03:26 MDT
This archive was generated by hypermail pre-2.1.9 : Sun Aug 01 2004 - 12:00:02 MDT