Include user ID and password in a link?

[Nigel Molesworth]

I've got a web cam that I'd like to access easily. The server needs a
user ID and password to log in.

Is there a way to Include user ID and password in a link?

--
Nigel M

[Benjamin Niemann]

Hello,

Nigel Molesworth wrote:

I've got a web cam that I'd like to access easily. The server needs a
user ID and password to log in.

Is there a way to Include user ID and password in a link?

This depends on how the authentication works.
If it is HTTP authentication, you could try
<http://USERNAME:PA****@www.example.com/path/to/something>,
though support for this has been disabled in IE for a while.
If there is a HTML form where you have to insert the credentials and the
server-side code happends to support the GET method, you have to lookup the
names of the controls and use something like
<http://www.example.com/path/to/something?uname=USERNAME&pwd=PASSWORD>.

But it is probably easier to just use a browser with built-in password
management - don't know about the IE line, but every other browser I know
of has it.
HTH
--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://pink.odahoda.de/

[Michael Fesser]

..oO(Benjamin Niemann)

>This depends on how the authentication works.
If it is HTTP authentication, you could try
<http://USERNAME:PA****@www.example.com/path/to/something>,
though support for this has been disabled in IE for a while.

It was not "disabled", they just fixed a bug. Username and PW are not
allowed in a HTTP URL.

Micha

[Benjamin Niemann]

Michael Fesser wrote:

.oO(Benjamin Niemann)

>>This depends on how the authentication works.
If it is HTTP authentication, you could try
<http://USERNAME:PA****@www.example.com/path/to/something>,
though support for this has been disabled in IE for a while.

It was not "disabled", they just fixed a bug. Username and PW are not
allowed in a HTTP URL.

Being more tolerant than a spec is not a bug - as long as the spec does not
enforce a specific error handling.
Adding extra features on top a spec might be a bad decision though. And it
was in this case, when phishers started to exploit it.

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://pink.odahoda.de/

[Harlan Messinger]

Benjamin Niemann wrote:

Michael Fesser wrote:

>.oO(Benjamin Niemann)

>>This depends on how the authentication works.
If it is HTTP authentication, you could try
<http://USERNAME:PA****@www.example.com/path/to/something>,
though support for this has been disabled in IE for a while.

It was not "disabled", they just fixed a bug. Username and PW are not
allowed in a HTTP URL.

Being more tolerant than a spec is not a bug - as long as the spec does not
enforce a specific error handling.

A feature that the spec doesn't explicitly provide for is not a bug. A
feature that the spec proscribes is a bug if the implementation is
intended to be compliant.

Adding extra features on top a spec might be a bad decision though. And it
was in this case, when phishers started to exploit it.

[Benjamin Niemann]

Harlan Messinger wrote:

Benjamin Niemann wrote:

>Michael Fesser wrote:

>>.oO(Benjamin Niemann)

This depends on how the authentication works.
If it is HTTP authentication, you could try
<http://USERNAME:PA****@www.example.com/path/to/something>,
though support for this has been disabled in IE for a while.
It was not "disabled", they just fixed a bug. Username and PW are not
allowed in a HTTP URL.

Being more tolerant than a spec is not a bug - as long as the spec does
not enforce a specific error handling.

A feature that the spec doesn't explicitly provide for is not a bug. A
feature that the spec proscribes is a bug if the implementation is
intended to be compliant.

The spec does not say (AFAIK, have only check it briefly, perhaps there's
something I have forgotten, since I read it more thoroughly) what to do
when an app encounters a malformed URL. Thus any action, including "Look
for a USERNAME:PASSWD@ part, remove it from the 'wannabe-URL' and try
again" is _not_ proscibed by the spec. Formally this is part of the error
recovery.
--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://pink.odahoda.de/

[Harlan Messinger]

Benjamin Niemann wrote:

Harlan Messinger wrote:

>Benjamin Niemann wrote:

>>Michael Fesser wrote:

.oO(Benjamin Niemann)

This depends on how the authentication works.
If it is HTTP authentication, you could try
<http://USERNAME:PA****@www.example.com/path/to/something>,
though support for this has been disabled in IE for a while.
It was not "disabled", they just fixed a bug. Username and PW are not
allowed in a HTTP URL.
Being more tolerant than a spec is not a bug - as long as the spec does
not enforce a specific error handling.

A feature that the spec doesn't explicitly provide for is not a bug. A
feature that the spec proscribes is a bug if the implementation is
intended to be compliant.

The spec does not say (AFAIK, have only check it briefly, perhaps there's
something I have forgotten, since I read it more thoroughly) what to do
when an app encounters a malformed URL. Thus any action, including "Look
for a USERNAME:PASSWD@ part, remove it from the 'wannabe-URL' and try
again" is _not_ proscibed by the spec. Formally this is part of the error
recovery.

OK, I was thinking in terms of the user name and password being treated
as valid on the server end if received. You're right, the client can
take anything and fix it up on the user's behalf to turn it into
something a compliant server can use.