IE Problem?

[Macoland]

I have been using WWW File Share Pro but I was not very happy with the features.  I came across this software but I am having a strange issue and I don't know why.  I am using version 2.0a.

I have HFS installed on a Windows 2003 server machine that I use as a web and file server.  I added a few real folders to HFS.  My testing has brought up a strange issue.  

I have the home or root locked so a username and password is required.  After logging in I can access the folders.  When I open a folder it works great, but if I then open another folder within the second folder I get a "The page cannot be displayed" error or a weird 301 error.  

For example root is /
I can open the live folder with no problem.  /live/

but when I open 1993 which is in the live folder   /live/1993

I either get a page error or an error like the one below

301 - Moved permanently to /Live/1993/


Now the strange thing is that I have tried it in IE, Opera, Netscape and Firefox and none of them have the problem except IE.  Which ironically will most likey be used to most to connect to the server.  

I did observe one thing though.  If I open the 1993 folder with Opera it gives me a security warning:

Security warning:

You are about to go to an address containing a username.

    Username: Master
    Server: 24.XXX.XX.XXX

Are you sure you want to go to this address?


So I found that to be weird, because it seems that it is asking for authentication again even though I already put in the name and password.  

I also found that if I remove the name and password protection it works in IE without a problem.  If anyone has any ideas I would appreciate it.  I have done a little bit of searching on the forums but didn't find anything related to this problem.  Thanks in advance for any help anyone could give me.  

-Macoland

[MarkV]

There is definately some weird behavior of IE (6.0SP2)...

Firefox:
1. Click Login link
2. Enter credentials
3. Login done

HFS log:

Code: [Select]

15.08.2006 00:47:19 192.168.1.100:2656 Connected
15.08.2006 00:47:19 192.168.1.100:2656 Got 514 bytes
15.08.2006 00:47:19 administrator@192.168.1.100:2656 Sent 94 bytes
15.08.2006 00:47:19 administrator@192.168.1.100:2656 Requested GET /~login
15.08.2006 00:47:19 administrator@192.168.1.100:2656 Request dump
> GET /~login HTTP/1.1
> Host: pluto:81
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
> Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://pluto:81/
> Authorization: Basic <authenticating string>==
15.08.2006 00:47:19 administrator@192.168.1.100:2656 Redirected to /
15.08.2006 00:47:19 administrator@192.168.1.100:2656 Disconnected by server - 94 bytes sent
15.08.2006 00:47:20 192.168.1.100:2657 Connected
15.08.2006 00:47:20 192.168.1.100:2657 Got 508 bytes
15.08.2006 00:47:20 administrator@192.168.1.100:2657 Sent 1148 bytes
15.08.2006 00:47:20 administrator@192.168.1.100:2657 Requested GET /
15.08.2006 00:47:20 administrator@192.168.1.100:2657 Request dump
> GET / HTTP/1.1
> Host: pluto:81
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
> Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://pluto:81/
> Authorization: Basic <authenticating string>==
15.08.2006 00:47:20 administrator@192.168.1.100:2657 Served 1,12 KB

[MarkV]

Now IE 6.0SP2

1. Click Login link
2. Enter credentials
3. Get a nice and shiny 'Page not found' error

HFS log:

Code: [Select]

15.08.2006 00:45:28 administrator@192.168.1.100:2544 Sent 118 bytes
15.08.2006 00:45:28 administrator@192.168.1.100:2544 Requested GET /~login
15.08.2006 00:45:28 administrator@192.168.1.100:2544 Request dump
> GET /~login HTTP/1.1
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/msword, */*
> Referer: http://pluto:81
> Accept-Language: de
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
> Host: pluto:81
> Connection: Keep-Alive
> Authorization: Basic <authentication string>==
15.08.2006 00:45:28 administrator@192.168.1.100:2544 Redirected to /
15.08.2006 00:45:28 administrator@192.168.1.100:2544 Disconnected by server - 212 bytes sent

Address bar of IE says http://pluto:81/~login. It seems the redirection to / fails for some reason.

MarkV

[ledufe]

hi guys after i googled a little, i've found this article

http://www.peej.co.uk/articles/http-auth-with-html-forms.html

witch says
...But there's a problem, IE doesn't support usernames and passwords in URLs, they were removed due to a security scare, and anyway, the HTTP spec doesn't say we're allowed to have URLs with usernames and passwords in them so we can't guarentee that they work anywhere else either.

read more here
http://support.microsoft.com/kb/834489

well hope it helps to find the reason of the trouble...

[Macoland]

That is very interesting and thanks for sharing the article.  The only problem is that with any other web server I have used IE works / worked fine with a username and password.  Oh well, I guess there is not much more that can be done..  :?

[Anonymous]

Please read also:

Naming and Addressing: URIs, URLs, ... http://www.w3.org/Addressing/

Timeline: News, Events, Publications, and History
This is a publication history, or bibliography collected from IETF documents and W3C Technical Reports as well as a record of events.

Jan 2005
Uniform Resource Identifier (URI): Generic Syntax [RFC3986] http://www.gbiv.com/protocols/uri/rfc/rfc3986.html

3.   Syntax Components
3.1.   Scheme
3.2.   Authority
3.2.1.   User Information

3.2.1. User Information
The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource. The user information, if present, is followed by a commercial at-sign ("@") that delimits it from the host.

   userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )

Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used.
Applications that render a URI for the sake of user feedback, such as in graphical hypertext browsing, should render userinfo in a way that is distinguished from the rest of a URI, when feasible. Such rendering will assist the user in cases where the userinfo has been misleadingly crafted to look like a trusted domain name (Section 7.6).

@ Rejetto:

Please reconsider the recent implementation of user:pass@url in HFS.
I know it was done to support download managers  <sarcasm mode> in the hand of noobs who don't know how to supply credentials </sarcasm mode>,
but security should have the highest priority.
______
GeeS

[Anonymous]

Thats why I've stayed with an older 2.1 beta version. I don't want
the obvious risk. I think people who use DL managers should be
smart enough to deal with a log in, if not.......... Oh, well !  

[~GeeS~]

same here.
Lot of problems with authentication with beta 15 ... coincidence?