Nic,
>>The base uri has nothing to do with basic authentication.
I don't think that's right. Firstly, RFC2617 states;
"The realm directive (case-insensitive) is required for all authentication schemes
that issue a challenge. The realm value (case-sensitive), in combination with the
canonical root URL (the absoluteURI for the server whose abs_path is empty; see
section 5.1.2 of [2]) of the server being accessed, defines the protection space."
My understanding is that the realm & absolute URI, define the protection space.
Therefore, two servlets with different canonical root URL's, but the same Realm name,
still define a different protection space.
I tested this with a simple servlet that issues a WWW--Autheticate for a realm of
"Development", and then just returned the authorisation string to the browser. I ran
the same servlet from two different locations
ie.
http://devlopment:8080/servlet/Auth
&
http://development:8080/alternate/Auth
After the first had run, the second would still prompt for authorisation.
Here's the program - if you have time you might like to try it yourself and verify the
results.
Thanks for your reply - if you have any futher suggestions for getting around the
issue, I would be grateful.
Regards,
Mick
import java.io.*;
import java.util.*;
import java.text.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Auth extends HttpServlet {
public void init(ServletConfig config) throws ServletException {
super.init(config);
}
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String authorisation = request.getHeader("Authorization");
if (authorisation == null) {
getAuth(response);
}
else {
out.println("<html>");
out.println("<body>");
out.println("<head>");
out.println("<title>Auth Example</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>Authorisation</h1>");
out.println("<h5>" + authorisation + "</h5>");
out.println("</body>");
out.println("</html>");
}
}
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
doGet(request, response);
}
private void getAuth(HttpServletResponse response) throws IOException
{
response.setStatus(response.SC_UNAUTHORIZED);
response.setHeader("WWW-Authenticate", "BASIC realm=\"Development\"");
}
}
>>> Nic Ferrier <[EMAIL PROTECTED]> 01/19/01 11:02PM >>>
>>> Mick McRae <[EMAIL PROTECTED]> 19-Jan-01 5:00:33 AM >>>
>The above form defines an action attribute with some
>servlet ie. http://host:8080/servlets/someServlet
>Because this servlet is using a different base URI to
>that of the original form, the browser doesn't send the
>currently cached authentication header.
The base uri has nothing to do with basic authentication (except in
common webserver configuration terms).
The question is whether the servlet sends the authentication
challenge with the same realm name to the browser.
>Is there anyway for the servlet, running under a
>particular URI, to request the authentication header
>from the browser, for a different URI?
No. But there is a way for the servlet to ask the browser to
authenticate against an arbritary relam name. That should force the
browser to send the details in recorded for the cgi program.
See my authentication FAQ which I seem to mention here everyday:
http://www.tapsellferrier.co.uk/Servlets/FAQ/authentication.html
>In this servlet I do some processing, create a
>HttpURLConnection object, and forward some
>of the form parameters onto another program
>which is in the same realm/URI as the original
>application. The program want's to send a
>WWW-authenticate back to my HttpURLConnectionObject.
>Of course, I don't have the authentication field from
>the original request, to forward in the HttpURLConnection
>object.
Once you have the authentication details you can pass them through
the HttpURLConnection as a header withiut even decoding them. You
don't need to recieve the WWW-Authenticate challenge first.
>Hope that makes some sense.
Hope you get on allright.
Nic
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
*******************************************************************
The information contained in this email and any files attached may
be confidential information to the intended recipient and may be
the subject of legal privilege or public interest immunity.
If you are not the intended recipient, any use, disclosure or
copying is unauthorised.
If you have received this document in error please telephone
+61 2 6243 5666.
*******************************************************************
This footnote also confirms that this email message has been swept
by MIMEsweeper for the presence of computer viruses.
*******************************************************************
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
