Thanks for your reply.
> Getting the user name and password
>
> String authorization = request.getHeader("Authorization");
> if (authorization == null) return 0;
>
> // Authorization headers looks like "Basic blahblah",
> // where blahblah is the base64 encoded username and
> // password. We want the part after "Basic ".
> String userInfo = authorization.substring(6).trim();
> BASE64Decoder decoder = new BASE64Decoder();
> String nameAndPassword = "";
> try{
> nameAndPassword = new
> String(decoder.decodeBuffer(userInfo));
> }catch ( IOException e ){}
> // Decoded part looks like "username:password".
> int index = nameAndPassword.indexOf(":");
> String user = nameAndPassword.substring(0, index);
> user = user.trim();
> if(user == null) return 0;
> String password = nameAndPassword.substring(index+1);
> password = password.trim();
> if(password == null) return 0;
Yes, but now how do you validate the password is correct and check which
roles? (Don't want to parse tomcat-users.xml, and we would like to be
able to use the LDAP etc. plug ins.) I don't think that JAAS is hooked
up at that level.
>
> To trigger the browser the headers look like this
> response.setStatus(response.SC_UNAUTHORIZED);
> response.setHeader("WWW-Authenticate", "BASIC
> realm=\"User Check\"");
Yes, that's essentially what I do. sendError is slightly better than
setStatus.
>
> Tomcat seems to only check the Authorization: headers if there is some
> <security-constraint> explicitly declared in web.xml. However, it
> appears that the optimization has been incorrectly implemented
because
> it does not then recheck the header if request.isUserInRole(...) etc.
> are called. So users cannot log into a system that uses
> request.isUserInRole(...).
>
> More specifically,
> my simple application tests request.isUserInRole(...) and
> request.getRemoteUser(). If the user lacks permissions the
application
> sends a 401, and the user is prompted for a name/password which is
sent
> back as a Authorization: Basic dGltOlBhc3N3b3JkMQ==
>
> So far so good. But Tomcat then ignores the Authorization: header
which
> is correctly sent by the browser.
>
> The web.xml has
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>Agile UI: tim/Password1</realm-name>
> </login-config>
> in it.
>
> There is no <security-constraint> clause in the web.xml because I do
not
> want to declare them there. (They are instead declared internally as
> part of a menuing system, which calls request.isUserInRole().)
>
> A hack to make Tomcat look at the Authorization: header is to add the
> following to web.xml
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>dbtest</web-resource-name>
> <url-pattern>/dbtest/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>dummy<role-name>
> </auth-constraint>
> </security-constraint>
>
> In which case it works if one accepts the unwanted dummy query.
>
> Is it possible to tell Tomcat to always check the Authorization:?
>
> Alternatively, is it possible to grant the dummy role to anonymous
> users? Do anonymous users have any role that could be added to a
dummy
> <security-constraint>?
>
> Is it possible for me to determine which users have which roles in my
> application so that I can check the header myself? Ie. get at the
> tomcat-users.xml style info, in a (fairly) web server independent
> manner?
>
> Or going the other way, is it possible for webapp to easily find out
> what roles are required for a given .jsp to run? (We want to grey out
> menu items that a user has no access to.)
>
> My general feeling is that attempting to use Java Servlet security is
> just wrong. One should simply do it oneself.
>
> Anthony
>
> --
> Dr Anthony Berglas
> Ph. +61 7 3227 4410
> (Mob. +61 42 783 0248)
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: [email protected]
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: [email protected]
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
