Re: [squid-users] squid - IE - ftp - WWW-authenticate question

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Mon, 16 May 2005 18:16:41 +0200 (CEST)

On Mon, 16 May 2005, Vinod Patel wrote:

> Now, a user requests ftp://hostname/ through his browser. Since the
> username and password are not mentioned in the url, squid tries to connect
> the remote-server using "anonymous" login and password. Now, if the remote
> server does not support "anonymous" login, it will reply with FTP code >
> 500. Example(in my case): "530 Can't set guest privileges". On seeing this,
> squid returns HTTP_FORBIDDEN(403) to the browser and the browser gets dumb.

The browser should show the error response.

However, MSIE tries to be smarter than it's own good. You need to disable
the "Show user friendly error messages" option for it to make any sense on
errors..

Note: ftp://hostname/ is specified as anonymous FTP in the Internet
standards on URL format.

Note2: Nearly no browsers follows the Internet standard on ftp:// URLs.

> BUT, i want the browser to ask for username and password when anonymous
> login fails. For this, i modified squid to return HTTP_UNAUTHORIZED(401) and
> send a "WWW-Authenticate" response-header, specifying the type of
> authentication and the realm.

Squid uses this to ask for the password on ftp://user@hostname/ requests,
but unfortunately MSIE does not support server authentication on ftp://
requests.

> On seeing "HTTP/1.0 401 Unauthorised", the browser should immediately
> look-up for "WWW-Authenticate" response-header, and POPUP a beautiful
> dialogue-box, asking us for username and password.

Should yes, but reality is different...

> This works fine for mozilla, netscape and firefox browsers. But
> Internet-Explorer does not. Instead of popping for username-password, it
> sits dumb. I tried googling on this, but all in vein. Finally, i found a
> site, which said that IE does not POPUP for 401 and "WWW-Authenticate".

Correct. Except that there is several versions of Mozilla where this
does not work proper.

> Most of my users use IE for browsing, so anyhow i needed it to popup. I
> got an ugly workaround for this. Instead of sending, 401(Unauthorised), i
> sent 407(Proxy Authentication Required) as response code. And used
> "Proxy-Authenticate" response-header as authentication-identifier. That
> worked for all browsers. Now all browsers ask for username-password whenever
> anonymous login fails. This could easily fool IE, but mozilla, netscape and
> firefox were too smart. On seeing 407 response code, they thaught it was
> proxy that needed authentication, and so while asking for username-password,
> they say "Enter username and password for proxy at IPADDRESS". That fools
> the users!!!

Well, 407 IS Proxy server authentication. If the browser claims anything
else it is plain wrong and is seriously fooling the users. The better this
is explained in the login dialog the better. So it is excellent that MSIE
explicitly states this in the login dialog. At least one thing they have
done correctly in this mess..

> Now question for you all experts:
> 1) Why does squid send HTTP_FORBIDDEN in case of any FTP error
> codes (>500). Can be more specific ?

In this case because it tries to follow the Internet standards, and
reports the error to the user indicating that the resource he requested is
not available and why.

> 2) If we leave IE, is "401 WWW-authenticate" a valid method of
> asking user for authentication ?

Yes, from what I can tell. But it is a somewhat grey zone as the official
method of providing the FTP username is within the URL

    ftp://user:password@host/

> 3) Is "407 proxy-authenticate", a better workaround for getting
> authentication information for original server ?

No, not at all. This is needed for proxy authentication.

> 4) Is there some other way to achieve this (popup for
> username-password in IE) ?

Javascripting in the error response to build the correct requested URL,
obviously provided you manage MSIE to show the error message... (it
should if you make the error message sufficiently large..)

> 5) Has anybody worked before on this kind of problem ?

Yes, but no very easy ways out..

The JavaScripting approach is perhaps the best of them all.

Regards
Henrik
Received on Mon May 16 2005 - 10:16:42 MDT

This archive was generated by hypermail pre-2.1.9 : Wed Jun 01 2005 - 12:00:03 MDT