Re: Problem with ftp proxying

From: Mike Wohlgemuth <[email protected]>
Date: Tue, 27 Jan 1998 09:55:05 -0500

In message <34C9B587.1562B81C@hem.passagen.se>, Henrik Nordstrom writes:
>Mike Wohlgemuth wrote:
>> =
>
>> >We have users who want to retrieve software via non-anonymous FTP.
>> >He can login FTP server with a password, but cannot retrieve any
>> >files expect under his home directroy.
>
>This is intentional, and according to the RFC 1738 specification. To
>reach outside the home directory on a UNIX (compatible) server you have
>to encode a / in the URL. http://server/%2f/some/path/file
>

I now realize that I was talking about a different problem. On
certain Unix FTP servers, while I can navigate around the
subdirectories under the home, I cannot retrieve any of the files.
Putting a '/' at the begining of the path in the RETR fixed these
problems, but I now realize it broke some other hosts. There seem to
be some cases where you can attach to the FTP server as an
authenticated user and not be in your home directory by default, which
is what do_retr seems to be assuming. I need to look at the source
more, I guess.

>Your fix to this not the best available, since it will make the password
>to show up in plain text even when the user is using authentication to
>provide the password. You should avoid URLs with encoded passwords as
>much as possible, and if IE does not support HTTP authentication from a
>http->ftp gateway (ftp proxy) then yell at Microsoft as this is very bad
>from a security perspective.

I agree. Unfortunately, some web sites that my users need to access
send back FTP URLs with encoded passwords. Yelling at Microsoft is
always high on my list of priorities. :-)

>If you do need to have the passwords in BASE HREF, then change "#ifdef
>NEVER_INCLUDE_PASSWORD" to #ifndef... This will make the password to
>show up when needed.

Thanks, I will get rid of my hack.

Mike
Received on Tue Jan 27 1998 - 06:59:12 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:38:32 MST