Authentication before redirection

[Larry Gillstrom]

Hi,

I'm hoping someone on this forum can help me.
I was wondering if it was possible to add/modify the authentication in the
headers before redirecting the client to a new url.

For example if you sent out these headers:
header('WWW-Authenticate: Basic realm="SomeRealm"');
header('HTTP/1.0 401 Unauthorized');

and then if the correct authorization was returned in

$_SERVER['PHP_AUTH_USER']
$_SERVER['PHP_AUTH_PW']

could you then modify those authentication values in the headers and then
redirect to a different url?

--
Larry Gillstrom

[Chung Leong]

Try this:

header("Location: http://username:pa******@somewhere.net/page.php");

Don't know if it still works in IE6.

Uzytkownik "Larry Gillstrom" <lg********@dccnet.com> napisal w wiadomosci
news:10*************@corp.supernews.com...

Hi,

I'm hoping someone on this forum can help me.
I was wondering if it was possible to add/modify the authentication in the
headers before redirecting the client to a new url.

For example if you sent out these headers:
header('WWW-Authenticate: Basic realm="SomeRealm"');
header('HTTP/1.0 401 Unauthorized');

and then if the correct authorization was returned in

$_SERVER['PHP_AUTH_USER']
$_SERVER['PHP_AUTH_PW']

could you then modify those authentication values in the headers and then
redirect to a different url?

--
Larry Gillstrom

[John Dunlop]

Chung Leong wrote upsidedown:

header("Location: http://username:pa******@somewhere.net/page.php");
Not only is that form of URL disallowed for http URLs (not that much
of anything pays attention to that) -- meaning your Location field
value violates RFC2616, which requires an absolute URL (and not many
browsers bother about that either) -- but, more importantly, sending
authentication details in URLs is a potential security risk.
Don't know if it still works in IE6.

Neither do I, and to be honest I'm not really interested. But going
by the user-contributed notes in the Manual's section on HTTP
authentication, "IE stopped supporting URLs in that format", whatever
that means.

--
Jock

[Wayne Pierce]

John Dunlop <jo*********@johndunlop.info> wrote in message news:<MP************************@News.Individual.N ET>...

Chung Leong wrote upsidedown:

header("Location: http://username:pa******@somewhere.net/page.php");
Not only is that form of URL disallowed for http URLs (not that much
of anything pays attention to that) -- meaning your Location field
value violates RFC2616, which requires an absolute URL (and not many
browsers bother about that either) -- but, more importantly, sending
authentication details in URLs is a potential security risk.

When I want to do a redirect like that I use output buffering. For
example:

<?php

// Start output buffering
ob_start();

// Do some stuff
if ($_SESSION['authStatus'])
{
header("Location: /login.php");
}

// Explicit flushing of the buffer
ob_end_flush();

?>

The down side to this approach is that nothing will be sent to the
browser until all of the processing is complete. However, you do not
need to worry about the error message concerning sending text before
sending the new header.

Don't know if it still works in IE6.

Neither do I, and to be honest I'm not really interested. But going
by the user-contributed notes in the Manual's section on HTTP
authentication, "IE stopped supporting URLs in that format", whatever
that means.

Due to the number of security incidents with flase URIs, Microsoft has
said that they will stop supporting that format in IE. People would
create a link something along the lines of
"ww**************@www.realsite.ru/login.php" where you would actually
go to the second portion of the link, when people thought they were
going to the first portion.

/s/ WP

[Chung Leong]

Uzytkownik "John Dunlop" <jo*********@johndunlop.info> napisal w wiadomosci
news:MP************************@News.Individual.NE T...

Chung Leong wrote upsidedown:

header("Location: http://username:pa******@somewhere.net/page.php");

Not only is that form of URL disallowed for http URLs (not that much
of anything pays attention to that) -- meaning your Location field
value violates RFC2616, which requires an absolute URL (and not many
browsers bother about that either) -- but, more importantly, sending
authentication details in URLs is a potential security risk.

[scratch head]

How's that not an absolute URL?

[Chung Leong]

Uzytkownik "Wayne Pierce" <wa***@mishre.com> napisal w wiadomosci
news:2a**************************@posting.google.c om...

Due to the number of security incidents with flase URIs, Microsoft has
said that they will stop supporting that format in IE. People would
create a link something along the lines of
"ww**************@www.realsite.ru/login.php" where you would actually
go to the second portion of the link, when people thought they were
going to the first portion.

The big question is whether they will just disallow the dot in the
username/password, or if the entire format is disabled all together. If
ftp://us**@somewhere.net is disabled too, that would create massive
disruption. On the other hand, it'd be pretty pointless if they stop only
the HTTP one.

[John Dunlop]

Chung Leong wrote:

Chung Leong wrote upsidedown:

header("Location: http://username:pa******@somewhere.net/page.php");

How's that not an absolute URL?

Because it does not conform to the syntax of http URLs.

RFC2396 defines the *generic* syntax of URIs; the syntax and
semantics of http URLs are defined in RFC2616, section 3.2.2 (and
formerly in RFC1738, section 3.3). There, we're given:

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

RFC2616, in a previous section, delegates RFC2396 to define the
components host, port and abs_path. The relevant excerpts from
RFC2396, then, are (not in original order):

host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit

alphanum = alpha | digit
alpha = lowalpha | upalpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"

The only characters allowed in the host component of an http URL,
therefore, are alphanumerics, periods and hyphens, with further
constraints on what can appear where. Although RFC2396 allows the
format user:password@hostport in URIs, it is forbidden in http URLs;
it was *expressly* prohibited by RFC1738 -- "No user name or password
is allowed." -- so relying on it being allowed would be unwise.

--
Jock

[Matthias Esken]

"Chung Leong" <ch***********@hotmail.com> schrieb:

The big question is whether they will just disallow the dot in the
username/password, or if the entire format is disabled all together. If
ftp://us**@somewhere.net is disabled too, that would create massive
disruption. On the other hand, it'd be pretty pointless if they stop only
the HTTP one.

http://user:pa******@example.com is no valid URI according to the RFCs.

ftp://user:pa******@example.com is a valid URI according to the RFCs.

Regards,
Matthias