How to set Http Request Header?

[Yuri Mikhel]

I am writing a servlet to perform single signon to an application
that uses Basic Authetication. This 3rd party application is running
on a different server (may not be Java based). I have stored the
usernames and passwords for this app in an external LDAP server. So, I
can retrieve them, encode them in Base64 and send the header via a URL
Connection. Here's my code:

URL url = new URL("http://some.external.server/loginpage");
URLConnection postUrlConnection = url.openConnection();

postUrlConnection.setDoOutput(true);
postUrlConnection.setUseCaches(false);
postUrlConnection.setRequestProperty("Content-Type",
"application/x-www-form-urlencoded");
postUrlConnection.setRequestProperty("Authorization", "Basic
c3lSTdGVduwWlYmwvZ2xj");

//I cannot call connect() if I need to read the stream - WHY?
//postUrlConnection.connect();

InputStream postInputStream = postUrlConnection.getInputStream();

BufferedReader postBufferedReader = new BufferedReader(new
InputStreamReader(postInputStream));
String postline = null;
while((postline = postBufferedReader.readLine()) != null) {
out.println(postline);
}

The servlet is able to login to the application, and it is returning
the page that I am suppose to see as if I log in directly thru the
URL.


I have 2 problems:

1. The returned page has images, files, and URL links that is relative
to the server I am connecting to. But, the client is actually
connected to my servlet on my machine. So, all the links are broken
and I can't get the images. Do I need to do URL re-writing for the
images/links to work? Can I do a sendRedirect() on the response and
yet still authenticated to the server?

2. I copied an URL that I know exist on the application to the
browser. Since my servlet (not the browser) was sending the auth
header, I was not able to go to that page on that application. The
application is asking me to login again with the Basic Auth dialog.
This tells me that the browser did not send the authorization header
on my next request. How do I store the authorization header created by
the servlet INTO THE BROWSER, so that it will be sent on all
subsequent requests?

Please help. Thanks.

 

[Oscar kind]

1. The returned page has images, files, and URL links that is relative
to the server I am connecting to. But, the client is actually
connected to my servlet on my machine. So, all the links are broken
and I can't get the images. Do I need to do URL re-writing for the
images/links to work? Can I do a sendRedirect() on the response and
yet still authenticated to the server?

Both will work if you have problem 2 solved.

2. I copied an URL that I know exist on the application to the
browser. Since my servlet (not the browser) was sending the auth
header, I was not able to go to that page on that application. The
application is asking me to login again with the Basic Auth dialog.
This tells me that the browser did not send the authorization header
on my next request. How do I store the authorization header created by
the servlet INTO THE BROWSER, so that it will be sent on all
subsequent requests?

You don't. It is a browser's choice to send this header or not, and only
the user can enter it.

The only thing you can send to the browser and get it back is a cookie.
This is also what is used by application servers to associate a session
with a browser.

 

[Asher Blum]

I have 2 problems:

1. The returned page has images, files, and URL links that is relative
to the server I am connecting to. But, the client is actually
connected to my servlet on my machine. So, all the links are broken
and I can't get the images. Do I need to do URL re-writing for the
images/links to work? Can I do a sendRedirect() on the response and
yet still authenticated to the server?

Are the images, files and URLs relative or absolute? Example of a
relative URL: "/images/up_arrow.gif". Example of an absolute URL:
"http://some.org/images/up_arrow.gif".

If they are relative, you can add a <base href> element to the head
of the document before returning it to the client. Example:

2. I copied an URL that I know exist on the application to the
browser. Since my servlet (not the browser) was sending the auth
header, I was not able to go to that page on that application. The
application is asking me to login again with the Basic Auth dialog.
This tells me that the browser did not send the authorization header
on my next request. How do I store the authorization header created by
the servlet INTO THE BROWSER, so that it will be sent on all
subsequent requests?

You can insert authentication into a URL:

http://joebob:[email protected]/somefile.html

If you return such a modified URL to the client, the client should be able
to access the URL without further authentication.

Hope this helps.

 

[Mark Marcus]

On Sun, 19 Sep 2004 21:25:39 GMT, Asher Blum wrote:

....SNIP...

You can insert authentication into a URL:

http://joebob:[email protected]/somefile.html

If you return such a modified URL to the client, the client should be able
to access the URL without further authentication.

Microsoft IE no longer accepts userw@.... formats anymore (as a
default). A user has to use REGEDIT to allow this format. It's yet
another example of how Microsoft doesn't know how to fix code, so they
break standards.

 

[Chris Uppal]

Microsoft IE no longer accepts userw@.... formats anymore (as a
default). A user has to use REGEDIT to allow this format. It's yet
another example of how Microsoft doesn't know how to fix code, so they
break standards.

While I'm no more impressed than anyone by MS's dismal record of security holes
badly patched with security hacks, you are being overly harsh here. MS's
standards-breaking error was that they accepted the userw@ notation in the
first place, not that they later removed it.

If you check RFC2616, section 3.2.2 you'll find that it does /not/ allow the @
notation in an HTTP URL, specifically it gives the grammar as:

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

It references RFC2396 (which does mention the @ syntax, but that's a much more
general document than RFC2616) for the meaning of 'host', 'port' etc. If it
were intended to allow the @ syntax, then it would use different terms from
RFC2396; and might read:

http_URL = "http:" "//" server [ abs_path [ "?" query ]]

where (from 2396):

server = [ [ userinfo "@" ] hostport ]
hostport = host [ ":" port ]

Incidentally, even RFC2396 discourages the use of "userinfo" as a
<name>:<password> pair. Quote:

Some URL schemes use the format "userassword" in the userinfo
field. This practice is NOT RECOMMENDED, because the passing of
authentication information in clear text (such as URI) has proven to
be a security risk in almost every case where it has been used.

-- chris

 

[Mark Marcus]

Microsoft IE no longer accepts userw@.... formats anymore (as a
default). A user has to use REGEDIT to allow this format. It's yet
another example of how Microsoft doesn't know how to fix code, so they
break standards.

While I'm no more impressed than anyone by MS's dismal record of security holes
badly patched with security hacks, you are being overly harsh here. MS's
standards-breaking error was that they accepted the userw@ notation in the
first place, not that they later removed it.

If you check RFC2616, section 3.2.2 you'll find that it does /not/ allow the @
notation in an HTTP URL, specifically it gives the grammar as:

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

It references RFC2396 (which does mention the @ syntax, but that's a much more
general document than RFC2616) for the meaning of 'host', 'port' etc. If it
were intended to allow the @ syntax, then it would use different terms from
RFC2396; and might read:

http_URL = "http:" "//" server [ abs_path [ "?" query ]]

where (from 2396):

server = [ [ userinfo "@" ] hostport ]
hostport = host [ ":" port ]

Yes, it does reference 2396, it didn't obsolete it. 2396 _is_ the
standard for the URI. Section 3 of 2396 states that the syntax for a
URI is:

3. <scheme>://<authority><path>?<query>
3.2 authority = server | reg_name
3.2.2 server = [ [ userinfo "@" ] hostport ]

It is true that the RFC recommends against the use of the userinfo
data for the reasons you cite, but that doesn't justify the decision
not to support it. If the RFC intended it never to be supported, an
update would have been issued that would have removed it from the
syntax.

This last is the likely reason that non-IE browsers (still) support
the feature, while Microsoft does not. Microsoft admits that the
reason they stopped supporting the feature was because of a security
hole in IE. Rather than fix the security hole, they chose to not
support the feature. See:

http://support.microsoft.com/default.aspx?scid=kb;en-us;834489



Mark Marcus
Protect Your Email Address and Make Money too!
http://www.xhome.org My Sales Code is 22819

 

[Chris Uppal]

Mark Marcus wrote:

[I'm leaving most of this unsnipped since the original messages may well have
expired]

Microsoft IE no longer accepts userw@.... formats anymore (as a
default). A user has to use REGEDIT to allow this format. It's yet
another example of how Microsoft doesn't know how to fix code, so they
break standards.

While I'm no more impressed than anyone by MS's dismal record of
security holes badly patched with security hacks, you are being overly
harsh here. MS's standards-breaking error was that they accepted the
userw@ notation in the first place, not that they later removed it.

If you check RFC2616, section 3.2.2 you'll find that it does /not/
allow the @ notation in an HTTP URL, specifically it gives the grammar
as:

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

It references RFC2396 (which does mention the @ syntax, but that's a
much more general document than RFC2616) for the meaning of 'host',
'port' etc. If it were intended to allow the @ syntax, then it would
use different terms from RFC2396; and might read:

http_URL = "http:" "//" server [ abs_path [ "?" query ]]

where (from 2396):

server = [ [ userinfo "@" ] hostport ]
hostport = host [ ":" port ]

Yes, it does reference 2396, it didn't obsolete it. 2396 _is_ the
standard for the URI.

No, I agree that it doesn't obselete it. However 2396 is the standard for URI
/in general/, and it doesn't take precedence over specific RFCs.

Section 3 of 2396 states that the syntax for a
URI is:

3. <scheme>://<authority><path>?<query>
3.2 authority = server | reg_name
3.2.2 server = [ [ userinfo "@" ] hostport ]

Again, that's the syntax for /general/ URI (with server addresses). There is
nothing to mandate that any given url scheme /must/ follow that pattern.

RFC 2616 is quite explicit that it doesn't allow userinfo, since it gives its
own syntax for http_URL that /does not/ follow the general pattern in 2396.

-- chris

 

[Mark Marcus]

Mark Marcus wrote:

Section 3 of 2396 states that the syntax for a
URI is:

3. <scheme>://<authority><path>?<query>
3.2 authority = server | reg_name
3.2.2 server = [ [ userinfo "@" ] hostport ]

Again, that's the syntax for /general/ URI (with server addresses). There is
nothing to mandate that any given url scheme /must/ follow that pattern.

RFC 2616 is quite explicit that it doesn't allow userinfo, since it gives its
own syntax for http_URL that /does not/ follow the general pattern in 2396.

RFC 2616 describes the HTTP protocol. What you type into a browser
address bar is not the protocol, it's a URI or a URL. You will note
that RFC 2616 Sections 3.2.1 and 3.2.2 does not describe any scheme
other than http: (since this is the only scheme that an HTTP server
need concern itself about).

The browser's address window, though, supports a more general
URI--some of which may connect to an HTTP server, others to a telnet
server, still others to FTP servers.

Now, the *HTTP* syntax http://user:password@host:port/path
functionality is described in RFC 2616 in Section 14.8--which
references another RFC 2617.

So in short, the syntax described in 2396 is a valid URI syntax
supportable by HTTP servers. And Microsoft dropped the ball in their
decision to no longer support it.

-- chris

Mark Marcus
Protect Your Email Address and Make Money too!
http://www.xhome.org My Sales Code is 22819

 

[Chris Uppal]

RFC 2616 describes the HTTP protocol. What you type into a browser
address bar is not the protocol, it's a URI or a URL. You will note
that RFC 2616 Sections 3.2.1 and 3.2.2 does not describe any scheme
other than http: (since this is the only scheme that an HTTP server
need concern itself about).

Oddly enough, basically the same thought (that RFC2616 describes the
on-the-wire protocol, not the syntax of cross-refs in HTML, etc) occurred to me
this morning as I was drinking my breakfast. On thinking about it a little
more, I have to admit that I was wrong.

Now, the *HTTP* syntax http://user:password@host:port/path
functionality is described in RFC 2616 in Section 14.8--which
references another RFC 2617.

?? section 14.8 (and RFC2617) doesn't have anything to do with the
userassword@host syntax. Or do you just mean that they describe the
on-the-wire implementation of user/password validation ?

-- chris

 

[Mark Marcus]

Mark Marcus wrote:

?? section 14.8 (and RFC2617) doesn't have anything to do with the
userassword@host syntax. Or do you just mean that they describe the
on-the-wire implementation of user/password validation ?

-- chris

Yes, that's what I meant. You must be psychic! Thanks for
interpreting it right instead of jumping down my throat like my
colleagues would've. I should've paid more attention in english
class.




Mark Marcus
Protect Your Email Address and Make Money too!
http://www.xhome.org My Sales Code is 22819

 

[rajuSrinivasan]

I feel best solution is to use front end http web server(apache) so all request are relative go through front end server.

This slove both problems.