By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,865 Members | 1,717 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,865 IT Pros & Developers. It's quick & easy.

Include user ID and password in a link?

P: n/a
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
Nov 15 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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/
Nov 15 '06 #2

P: n/a
..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
Nov 15 '06 #3

P: n/a
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/
Nov 15 '06 #4

P: n/a
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.
Nov 15 '06 #5

P: n/a
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/
Nov 15 '06 #6

P: n/a
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.
Nov 15 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.