[squid-users] Problem with proxy auth PXY2 - update

Hi all,

Further to my diatribe below regarding redirector_access TAG below

Switched on debug of both with and without. With the acl check the
redirector call fails, without it works.
Unfortunately, without in 2.5STABLE1 it does not appear to send the proxy
auth id to the redirector, hence I cannot use userlist rules.

Is this a bug in 2.5, can anyone come back to me because I really want to
use the proxy auth id in userlists in the redirector (SquidGuard).

Bottom line is what is the
2003/02/27 12:36:06| authenticateAuthenticate: no connection data, cannot
proces authentication

error message which is causing the problem

Cheers, can someone please help!

TAG and logs below:-

Redirector_access allow passwordauth { proxy_auth acl }

Cache.log with
2003/02/27 12:36:06| aclMatchAclList: returning 1
2003/02/27 12:36:06| cbdataUnlock: 0x8211950
2003/02/27 12:36:06| aclCheck: match found, returning 1
2003/02/27 12:36:06| aclCheckCallback: answer=1
2003/02/27 12:36:06| cbdataValid: 0x83ec068
2003/02/27 12:36:06| The request GET
http://www.hotsex.com/sex_exits/teenlive.j
g is ALLOWED, because it matched 'passwordauth'
2003/02/27 12:36:06| redirectStart:
'http://www.hotsex.com/sex_exits/teenlive.j
g'
2003/02/27 12:36:06| aclCheckFast: list: 0x8211278
2003/02/27 12:36:06| aclMatchAclList: checking passwordauth
2003/02/27 12:36:06| aclMatchAcl: checking 'acl passwordauth proxy_auth
REQUIRE
'
2003/02/27 12:36:06| authenticateAuthenticate: no connection data, cannot
proce
s authentication
2003/02/27 12:36:06| aclMatchAcl: returning 0 user authenticated but not
autho
ised.
2003/02/27 12:36:06| aclMatchAclList: returning 0
2003/02/27 12:36:06| aclCheckFast: no matches, returning: 0

Cache.log without

2003/02/27 12:46:10| aclMatchAclList: returning 1
2003/02/27 12:46:10| cbdataUnlock: 0x82118e8
2003/02/27 12:46:10| aclCheck: match found, returning 1
2003/02/27 12:46:10| aclCheckCallback: answer=1
2003/02/27 12:46:10| cbdataValid: 0x83db6a8
2003/02/27 12:46:10| The request GET http://www.hotsex.com/ is ALLOWED,
because
it matched 'passwordauth'
2003/02/27 12:46:10| redirectStart: 'http://www.hotsex.com/'
2003/02/27 12:46:10| cbdataLock: 0x83db6a8
2003/02/27 12:46:10| cbdataLock: 0x83dfe50
2003/02/27 12:46:10| cbdataValid: 0x83dfe50
2003/02/27 12:46:10| comm_write: FD 7: sz 53: hndl (nil): data (nil).
2003/02/27 12:46:10| commSetSelect: FD 7 type 2
2003/02/27 12:46:10| commSetSelect: FD 7 type 1
2003/02/27 12:46:10| helperDispatch: Request sent to redirector #1, 53 bytes
2003/02/27 12:46:10| helperSubmit: http://www.hotsex.com/ 192.168.90.105/-
osul
ivd GET

-----Original Message-----
From: David O'Sullivan
Sent: 27 February 2003 10:16
To: 'squid-users@squid-cache.org'
Subject: Problem with proxy auth PXY2

All,

I have only recently been using Linux and Squid (about 5-6weeks Linux , 4
weeks squid ). 3 weeks ago or so I asked about forcing an initial policy
page prior to proxy auth request. The responses are at the bottom of this
very long explanation, but they essentially meant I would have to move to
squid 2.5.
At the time I was running SUSE installed Squid2.4 STABLE7 version. I have
now taken the Squid 2.5 STABLE1 copy from the squid-cache.org website and
compiled as per instructions
I am also using squidGuard 1.2 delivered with SUSE.

Unfortunately I now have some new problems/opportunities

In 2.4 STABLE7 I was using a redirector_access TAG to only send proxy
authenticated requests to the redirector (SQuidGuard). This seemed to work
quite well and I was able to also group squidGuard acls based on the proxy
auth ID.

THE PROBLEM
With the 2.5STABLE1 the redirector is not called at all and the following
message appears in the cache.log

2003/02/27 09:30:54| authenticateAuthenticate: no connection data, cannot
proces authentication

If I allow all requests to go via the redirector, i.e. remove the
redirector_access TAG then the grouping of users based on their proxy
authenticated auth ID in SquidGuard fails to work and so all are treated the
same.
Anyone know what the fix is for this problem as it basically means I cannot
treat access to banned sites differently based on their proxy auth ID which
I really would like to achieve.

SIDE EFFECT
Having moved to 2.5STABLE 1 it was interesting to note that the problem I
was getting on my browser IE6 SP1 has now gone away and the authentication
box now allows retries if the password is typed incorrect. Anyone else
notice this?

Thanks in advance, I am really stuck!

Cheers Dave O'Sullivan

Conf files below

SQUID.CONF for 2.4 STABLE7
acl passwordauth proxy_auth REQUIRED

redirector_access allow passwordauth
                    {this was moved below the passwordauth acl in the conf
file because in it's default place it did not parse
properly}

http_access allow passwordauth

authenticate_program /usr/sbin/ncsa_auth /path/to/passwddir/passwd

SQUID.CONF for 2.5STABLE1
acl passwordauth proxy_auth REQUIRED

redirector_access allow passwordauth
                    
http_access allow passwordauth
auth_param basic program /usr/sbin/ncsa_auth /path/to/passwddir/passwd
auth_param basic children 5
auth_param basic realm proxy-caching web server
auth_param basic credentialsttl 2 hours

SQUIDGUARD.CONF
src admin {
    ip # Firewall IP
    user foo
}

src generalstaff {
    ip # Firewall IP
}

dest blacklist {
    domainlist blacklist/domains
    urllist blacklist/urls
    log porn.log
}

acl {
    admin {
        pass all
    }
    generalstaff {
        pass !in-addr !blacklist all
    }

Original responses about forcing a policy page prior to proxy auth
        Robert Collins wrote:

> Requests without authentication are redirected to the policy page,

> with the original page in a cookie/form submission. The policy
page
        obert Collins wrote:

> Requests without authentication are redirected to the policy page,

> with the original page in a cookie/form submission. The policy
page
> sets a cookie "POLICY ACCEPTED" when the user accepts the policy.
The
> policy web server *must* be accessed via squid.
>
> When a request to the policy webserver, with a policy accepted
cookie,
> is seen, authentication is triggered, and the user redirected back
to
> the originally requested page.
 
        Yes, this looks like it might be done.

        external_acl_type can be used to filter out requests without proxy
authentication, or a extension acl can be written within Squid to do the
same. deny_info url capability of Squid-3 (also available as a patch to
        Squid-2.5) can then be used to redirect the request to the policy
page.

        The same scheme can also be used to IP based session timers, having
an external_acl_type acting as a filter on which requests may need to
be sent to the policy page, and the cookie as the definite filter on
which users have accepted the policy or not.

        Regards
        Henrik

This e-mail and its attachments are confidential and intended solely for the
addressee. If you are not the intended addressee, you must not disclose,
forward, copy or take any action in respect of this email or any
attachments. If you have received this e-mail in error, please delete it and
notify the sender. While ADM and Optecon have taken every reasonable
precaution to minimise this risk, we cannot accept liability for any damage,
which you may sustain as a result of software viruses. You should carry out
your own virus checks before opening the attachment.
Received on Thu Feb 27 2003 - 05:59:05 MST