On 9/03/2012 6:16 p.m., Brett Lymn wrote:
On Thu, Mar 08, 2012 at 10:37:01AM +1030, Brett Lymn wrote:
1) The credentials being passed to the upstream are not rewritten - if I
decode the basic auth it has my real password going to the upstream.
And scratch this one too... if I use:
cache_peer
On Thu, Mar 08, 2012 at 10:37:01AM +1030, Brett Lymn wrote:
1) The credentials being passed to the upstream are not rewritten - if I
decode the basic auth it has my real password going to the upstream.
And scratch this one too... if I use:
cache_peer upstream.proxy parent 8080 7
On 7/03/2012 4:49 p.m., Brett Lymn wrote:
On Wed, Mar 07, 2012 at 03:44:23PM +1300, Amos Jeffries wrote:
cache_peer option of login=PASS, with the external_acl_type helper
returning values in both user= and password= parameters.
OK, I must be doing something dumb. I have the following in the
On Wed, Mar 07, 2012 at 11:58:31PM +1300, Amos Jeffries wrote:
cache_peer_access is a fast group access list. This is why suggested
never/always _direct lists for the testing.
Yep, me being dumb :) I did as you suggested and used the never_direct
deny and my debug lines in the external
On Thu, Mar 08, 2012 at 10:37:01AM +1030, Brett Lymn wrote:
2) For some unknown (to me) reason the upstream is prompting for auth
even though the basic auth header is there. It does not do this if I
have login=*:password but if I set login=PASS the upstream prompts.
Scratch this one - the
Following up on myself...
On Fri, Mar 02, 2012 at 01:59:27PM +1030, Brett Lymn wrote:
At the moment I am looking at setting up a LDAP proxy for the upstream
to query and then use login=*:password in squid. This should allow me
to make the upstream proxy believe it is authenticating so that
On 07.03.2012 14:23, Brett Lymn wrote:
Following up on myself...
On Fri, Mar 02, 2012 at 01:59:27PM +1030, Brett Lymn wrote:
At the moment I am looking at setting up a LDAP proxy for the
upstream
to query and then use login=*:password in squid. This should allow
me
to make the upstream
On 07.03.2012 15:44, Amos Jeffries wrote:
On 07.03.2012 14:23, Brett Lymn wrote:
Following up on myself...
On Fri, Mar 02, 2012 at 01:59:27PM +1030, Brett Lymn wrote:
At the moment I am looking at setting up a LDAP proxy for the
upstream
to query and then use login=*:password in squid.
On Wed, Mar 07, 2012 at 03:44:23PM +1300, Amos Jeffries wrote:
cache_peer option of login=PASS, with the external_acl_type helper
returning values in both user= and password= parameters.
OK, I must be doing something dumb. I have the following in the config:
cache_peer upstream.parent
On 01.03.2012 18:06, Brett Lymn wrote:
On Thu, Mar 01, 2012 at 03:17:43PM +1030, Michael Hendrie wrote:
I have a commercial web filtering and reporting product (although I
think different from yours) that can also make use of the
X-Authenticated-User header (as well as other user
On 02.03.2012 00:06, Michael Hendrie wrote:
On 01/03/2012, at 7:32 PM, Amos Jeffries wrote:
On 01.03.2012 18:06, Brett Lymn wrote:
On Thu, Mar 01, 2012 at 03:17:43PM +1030, Michael Hendrie wrote:
snip
I'm reluctant to add the header because the data is already
transmitted in the
On Thu, Mar 01, 2012 at 10:02:06PM +1300, Amos Jeffries wrote:
Can't you just support proper authentication?
I can but I have problems if I try and use kerberos for authentication.
I have kerberos working fine with squid, the auth works ok - I even have
it working correctly with the squids
On Fri, Mar 02, 2012 at 12:41:11AM +1300, Amos Jeffries wrote:
You really want to trust a tutorial which begins with Enable SSL
interception on the proxy server.?
Unfortunately, want has little to do with this. I get no say in whether
or not we have what we have I am just the bunny that
On 2/03/2012 11:53 a.m., Brett Lymn wrote:
On Thu, Mar 01, 2012 at 10:02:06PM +1300, Amos Jeffries wrote:
Can't you just support proper authentication?
I can but I have problems if I try and use kerberos for authentication.
I have kerberos working fine with squid, the auth works ok - I even
On Fri, Mar 02, 2012 at 03:29:22PM +1300, Amos Jeffries wrote:
You really need that functionality from 3.2 then.
* login=NEGOTIATE to have one key representing your Squid and all
users going through it. Or at least one key peer cache_peer line ;)
Unfortunately I really need to stick with a
I have an application that pays attention to the X-Authenticated-User
header. I need to use this application as an upstream proxy and need to
have the user authentication passed from squid through to this
application. I know about the login=PASS cache_peer directive but I am
wondering how that
On 01.03.2012 14:32, Brett Lymn wrote:
I have an application that pays attention to the X-Authenticated-User
header.
Why? what does it do?
I need to use this application as an upstream proxy and need to
have the user authentication passed from squid through to this
application.
What
On Thu, Mar 01, 2012 at 03:07:42PM +1300, Amos Jeffries wrote:
On 01.03.2012 14:32, Brett Lymn wrote:
I have an application that pays attention to the X-Authenticated-User
header.
Why? what does it do?
Apparently, it believes it. I don't _think_ it actually does any
further
On 01/03/2012, at 1:45 PM, Brett Lymn wrote:
On Thu, Mar 01, 2012 at 03:07:42PM +1300, Amos Jeffries wrote:
On 01.03.2012 14:32, Brett Lymn wrote:
I have an application that pays attention to the X-Authenticated-User
header.
Why? what does it do?
Apparently, it believes it. I don't
On Thu, Mar 01, 2012 at 03:17:43PM +1030, Michael Hendrie wrote:
I have a commercial web filtering and reporting product (although I think
different from yours) that can also make use of the X-Authenticated-User
header (as well as other user identification methods).
I have previously
20 matches
Mail list logo