I believe that Craig's answer properly explains the multiple-instance issue. If you need your servlet to do more interesting authentication than your HTTP server's ACLs support (e.g., against a special user DB), try sub-classing the attached servlet code. Happy programming, LT At 12:14 PM 12/17/1999 -0500, you wrote: >Does anyone have experience of using Basic Authentication >to define access to individual servlet instances of the same >servlet code? > >I am using WebSphere 1.1 & Netscape Enterprise Server 3.5. > >I would like to register multiple aliases (servlet instances) >in my servlet.properties file that look like so: > >MyServletChannel1 com.csfb.gfx.servlets.ChannelServlet >MyServletChannel2 com.csfb.gfx.servlets.ChannelServlet >MyServletChannel3 com.csfb.gfx.servlets.ChannelServlet >MyServletChannel4 com.csfb.gfx.servlets.ChannelServlet > >This means that a url http://mywebserver/servlet/MyServletChannel1 >refers to a different servlet instance, than >http://mywebserver/servlet/MyServletChannel2 >with both instances having the same code. > >My question is - how can I configure basic authentication so that >different users have access to MyServletChannel1 and MyServletChannel2 ? > >Peter Booth >[EMAIL PROTECTED] > >This message is for the named person's use only. It may contain >confidential, proprietary or legally privileged information. No >confidentiality or privilege is waived or lost by any mistransmission. >If you receive this message in error, please immediately delete it and all >copies of it from your system, destroy any hard copies of it and notify the >sender. You must not, directly or indirectly, use, disclose, distribute, >print, or copy any part of this message if you are not the intended >recipient. CREDIT SUISSE GROUP, CREDIT SUISSE FIRST BOSTON, and each of >their subsidiaries each reserve the right to monitor all e-mail >communications through its networks. Any views expressed in this message >are those of the individual sender, except where the message states >otherwise and the sender is authorised to state them to be the views of >any such entity. > >___________________________________________________________________________ >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 > >
import javax.servlet.*; import javax.servlet.http.*; /** * Base-class for servlets that perform HTTP/401 authentication. * To extend this, simply sub-class it and implement * <CODE>boolean isValidAccount(username, password)</CODE> * (as well as <CODE>doGet()</CODE> or <CODE>doPost</CODE>). * @author <A HREF="mailto:[EMAIL PROTECTED]">Lenny Turetsky</A> */ public abstract class HttpAuthServlet extends HttpServlet { public static final String HTTP_AUTHENTICATION_HEADER = "Authorization"; public static final String HTTP_AUTHENTICATION_TYPE_BASIC = "Basic"; /** * Extending sub-classes must implement this function with * code that knows about their specific user-database. * @param Username as provided by the user-agent * @param Password as provided by the user-agent * @param Request available in case account authentication requires * checking cookies, IP address, URI, referer, etc.; in addition, * in addition, objects created in this method call can be * stored via HttpServletRequest.putValue() for later retrieval * in doGet() or doPost() * @return <CODE>true</CODE> if username/password/Request * is a valid combo; <CODE>false</CODE> otherwise */ abstract protected boolean isValidAccount(String Username, String Password, HttpServletRequest Request); public final void service(HttpServletRequest Request, HttpServletResponse Response) throws ServletException, java.io.IOException { String authHeader = getAuthHeader(Request); // are we using authentication? if (null != authHeader) { // yes // do we have a valid username and password? String authorization = Request.getHeader(HTTP_AUTHENTICATION_HEADER); String username = null; String password = null; if (null != authorization && authorization.startsWith(HTTP_AUTHENTICATION_TYPE_BASIC)) { // authorization header exists String encodedAuthorizationData = authorization.substring(HTTP_AUTHENTICATION_TYPE_BASIC.length() + 1); String decodedAuthorizationData = base64Decode(encodedAuthorizationData); int separatorLocation = decodedAuthorizationData.indexOf(":"); if (separatorLocation >= 0) { username = decodedAuthorizationData.substring(0, separatorLocation); password = decodedAuthorizationData.substring(separatorLocation+1); } else { // leave the username and password null } } else { // no authorization header // leave the username and password null } if (isValidAccount(username, password, Request)) { // valid // all is well, so call the "real" functionality super.service(Request, Response); // just calls doGet()/doPost() } else { // invalid username/password combo demandAuthentication(Request, Response); } } else { // no authentication provided // demand authentication demandAuthentication(Request, Response); } } private String getAuthHeader(HttpServletRequest Request) { return Request.getHeader(HTTP_AUTHENTICATION_HEADER); } private void demandAuthentication(HttpServletRequest Request, HttpServletResponse Response) { Response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); Response.setHeader("WWW-Authenticate", "Basic realm=\"" + getRealm(Request) + "\""); } private String base64Decode(String Base64Encoded) { return new String(com.protomatter.util.Base64.decode(Base64Encoded)); } /** * Sub-classes wishing to specify which "realm" the * client (user-agent) should authenticate against * should sub-class this method. * Usually, this can safely be ignored. */ public String getRealm(HttpServletRequest Request) { return "allcharities.com"; } }
-- The nice thing about being a cynic is that I enjoy being wrong.
