Search squid archive

Re: Confusing redirection behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave Coventry wrote:
In an attempt to generate a login page I was previously using
"external_acl_type" to define a helper program to define my acl, and
then using "deny_info" to define a logon page for my users.

This failed because the redirected page did not appear to use it's own
URL as it's root and instead substituted the requested URL.

So the (perhaps too) simple course of action would be to use absolute rather than relative links in the HTML of the error page.

...<form action="http://192.168.60.254/cgi-bin/myperlscript.cgi"; name=login>...

instead of

...<form action="/cgi-bin/myperlscript.cgi" name=login>...

This meant that I was unable to call a CGI from my logon form because
the form's CGI was appended to the originally requested (and denied)
URL. So, if the user requested "toyota.co.za", and was (correctly)
sent to my login "192.168.60.254/login.html", the CGI called from the
login page's form was "toyota.co.za/cgi-bin/myperlscript.cgi".

Which is a bit odd.  Looking through the history, I see you are using...

deny_info http://192.168.60.254 lan

... The documentation says that should result in a 302 (Moved Temporarily), and substitute the requested URL for %s (within the 302). Since you are not using %s in your deny_info line, all traces of the original requested URL should be lost, but given the experiences you had with accessing pages on the Apache instance on the same box(http://www.squid-cache.org/mail-archive/squid-users/200802/0767.html), I don't know. Perhaps using wireshark or tcpdump is going to be your best bet.

Amos suggested that, instead of hosting the cgi script on the server,
I placed it on the 'net, but I'm afraid this wouldn't suit my purpose.

In desperation I'm looking at "url_rewrite_program", but it also
appears to have redirection issues.

If I use the Perl script below, I would expect the requested URL to be
replaced by http://localhost/login.html, whatever the user requested.

However 2 results occur. If the requested URL is a simple tld, like
http://www.toyota.co.za, then the user is redirected to the Apache
default page which simply proclaims (misleadingly!) that "It Works!".
This in spite of the fact that the default page has been removed and
replaced.

If the URL takes the form
"http://www.google.co.za/firefox?client=firefox-a&rls=org.mozilla:en-GB:official";
then the user is presented with a 404 which says "firefox not found".
/var/log/apache/error.log confirms that "/var/www/firefox" is not
found.

This behaviour persists if I replace http://localhost with
http://192.168.60.254 or with http://news.bbc.co.uk, or whatever.

#!/usr/bin/perl
$|=1;
while (<>) {
    @X = split;
    $url = $X[0];
    $ip = $X[1];
    if (1 == 1){
        print "302:http://localhost/login.html\n";;

Hmmm... Once again, using the 302. wireshark or tcpdump would be the tools I would recommend at this point. Something funky is going on here.

    }
    else{
        print "$url\n";
    }
}

Chris

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux