Try using a '302:' on the redirect in your default acl. (That's the
one that goes to login.cgi, right?) So it would be:
redirect 302:http://yourserver.com/login.cgi
Without the 302: the browser shows the redirected page (login.cgi?)
while displaying the requested address (www.squidguard.org, in your
example). Adding the 302: will cause the browser to correctly
show the address of the login page.
Although it seems odd at first, redirecting without the 302:
is preferred for most redirects. If a user clicks on a link and
doesn't realize that it links to a page on www.playboy.com, he'll be
surprised when he receives a block page. Without the 302: the user
can look at the address and see where the link was trying to send
him. That's much more informative than the address of the block
page itself. And in the case of a block, it doesn't really matter
that the block page is being cached for www.playboy.com.
Your login.cgi is an entirely different matter. I think adding the
302: will solve the problem for you.
Rick
Fernando Henrique Giorgetti wrote:
> I am using SquidGuard (since 2001) to control my users access.
> But, its not its only task. Its used too, to login my users
> before them start their navigation, to apply dynamically an
> individual policy to each user by this way: When a not logged
> user (that does not have an src acl in squidguard.conf) tries
> to access something, he is redirected to a login.cgi that
> requests for user and password. After the user posts that
> information, he will be redirected again to a pre-defined website
> (for example: www.squidguard.org).
>
> The problem occurs when a user has a start page defined in his
> browser (for example www.squidguard.org). When the browser is
> opened, the user is redirected by squidguard to our login.cgi.
> So, the user posts his user/pass and after this the cgi will log
> him and redirect again to www.squidguard.org. Then, the browser
> begins an endless loop because it caches the start page as the
> login.cgi (that redirects the logged user to
> www.squidguard.org <- that is login.cgi to the browser).
>
> I had already put the cache headers in my html and cgi but I
> can't eliminate this problem.
>
> Do you know what's going on?
>
> Thanks,
>
> Fernando.
