Often you want to connect to a site to get data that requires a name and password, but you want a simple interface. For instance one that will work with LWP::Simple. The following form of a URL is documented but apparently not as widely known as it deserves to be.

It should work for all protocols.

EDIT
A piece of trivia. Hotmail has an interesting use for this. Their name/password form is submitted by https to a script that does nothing but redirect to a URL with the name and password inserted as above, that will require Digest authentication. The browser without prompting then uses the name and password (as originally typed in their form) and from then on has http authentication loaded.

Turning form entries into http authentication securely without encrypting your whole site is something that a lot of people think is impossible. Well it is not, and that is how you do it! :-)

http://name:password@www.somedomain.com/whatever/page.html

[download]

Replies are listed 'Best First'.
RE: Put name and password in URLs
by tenatious (Beadle) on Aug 26, 2000 at 22:10 UTC
    You can do this with ftp, as well. I know with netscape, it provides a single file drag and drop interface (on windows). You just call it like:

    ftp://name:password@your.server.net

[reply]
Re: Put name and password in URLs - except for IE :-(
by tilly (Archbishop) on Feb 01, 2004 at 21:07 UTC
    As of early 2004, Microsoft is removing support for this in Internet Explorer. Here are the details. This is their better fix to the bug that prompted them to tell people to type in URLs.

    For those who don't know, they have two reasons for doing this. The first is that users were getting mislead by URLs which used the name:password@ trick to make it look like they were going to a different site than they were really going to. The second is that if a URL includes %01 or %00 in it, then IE truncates the display of the URL there. So there is no way to see the real URL from within IE.

    I have not heard of any plans on their part to fix the second bug. Their solution to the first problem personally inconveniences me, but I can understand their justification.

    For anyone who used the advice above, please note that it will continue to work in all third-party browsers, ftp clients, software libraries like LWP, etc. But you can't rely on it in Internet Explorer going forward.

[reply]
Re (tilly) 1: Put name and password in URLs
by tilly (Archbishop) on Aug 22, 2001 at 19:39 UTC
    An addendum that I needed to look up. What do you do if the name or password contains special characters? Well the answer after reading RFC 1738 is that you just URI encode them. (Duh, I should have guessed.) You can do that with the URI::Escape module. Be warned, the default character set it escapes does not include @. Therefore you will want to use something like this: 
    use URI::Escape qw(uri_escape);

# Takes a list of strings, returns them escaped for use in URLs.  In s
+calar
# context will only escape the first.
sub safe_uri_escape {
  wantarray
    ? map {uri_escape($_, "\\W")} @_
    : uri_escape(shift, "\\W");
}

    [download]
[reply]
[d/l]
      I realize this thread is over two years old, but it caught my attention because I have been looking into deobfuscation of evil URLs, and I believe this is not a good idea, particularly in a HTTP URL.

      This field (called "userinfo") is defined in the general URI format in RFC 2396, but it is not used in the HTTP URL fomat described in RFC 2616. Nonetheless, most browsers will transmit this field unchanged, and most web servers will ignore it, but supply it to a CGI program as part of the "environment" data. Its chief application is intentionally obscuring the identity of the URL. It is used mainly by fraudsters and spammers for that purpose.

      In addition, here is a quote from RFC 2396:

      "It is clearly unwise to use a URL that contains a password which is intended to be secret. In particular, the use of a password within the 'userinfo' component of a URL is strongly disrecommended except in those rare cases where the 'password' parameter is intended to be public."

[reply]
        While I grant you that this can be used by fraudsters for social engineering purposes, it has many more legitimate uses. The most common one that I have had is to simplify automation of fetching web pages for batch jobs. You don't have to rewrite a script that used LWP::Simple or that passes stuff to lwp-request, you just add stuff to the URL.

        While I can't say for sure what people around here have used it for, all of the comments that I have received suggest that they used it for exactly what I did.

[reply]
RE: Put name and password in URLs
by Anonymous Monk on Nov 04, 2000 at 00:24 UTC
    tilly, Thanks! You just saved me hours and hours of tedious work.
[reply]

Back to Cool Uses for Perl