Re: [squid-users] Problems with Squid and non-anonymous FTP

From: Henrik Nordstrom <henrik@dont-contact.us>
Date: Tue, 22 Aug 2006 15:21:02 +0200

On Tue, 2006-08-22 at 08:52 -0400, Michael W. Lucas wrote:

> > ftp://user:password@host/
>
> That does work, but it's discouraged in the FAQ. I'd also rather not
> teach my users to type passwords in visible cleartext, I have enough
> trouble getting them to not use their passwords as desktop wallpaper. :-)

Then persuade the browser vendors to support HTTP authentication on
ftp://user@host/ links when using proxies. Squid does the best it can
and asks for authentication credentials, not sure what else we can do.

> a) anyone know how to make IE 6 SP 2 and/or Firefox 1.5 prompt for a
> password at a non-anonymous FTP site?

As a workaround/test you can use a redirector at the proxy, rewriting
some http:// address into the desired ftp address (with some user@ in
the host part, what does not matter, just to tell Squid that it's
non-anonymous). And all of a sudden the client understands how to do
authentication because now the URL starts with http:// instead of
ftp://. That's really the only difference in all other aspects, as in
both cases the client uses HTTP to the proxy..

> b) As this test cache does not require a username and password, why do
> I get a "Cache Access Denied" error saying that I am not allowed to
> request a non-anonymous FTP URL from the cache until I have
> authenticated myself?

Squid sends this when you give it an incomplete non-anonymous FTP url.
I.e. ftp://user@host/ without password. When seeing such URL Squid
requests authentication from the client, effectively asking it to fill
in the full credentials. It doesn't even attempt to connect to the FTP
server before having a full set of credentials to login with.

> Is it just passing through the "incorrect password" error from the FTP site?

The FTP gateway in Squid does not really care about the meaning of this
error. If the FTP server rejects the login when Squid thinks it has a
complete login the error is given back to the client verbatim indicating
that the PASS command failed. You saw this earlier I think.

In theory we could map this to HTTP authentication, requesting a new set
of credentials. Not complex to do, but does not solve the original
problem of clients not understanding how to do HTTP authentication on
ftp:// URLs.

Regards
Henrik
Received on Tue Aug 22 2006 - 07:19:54 MDT

This archive was generated by hypermail pre-2.1.9 : Fri Sep 01 2006 - 12:00:02 MDT