En l'instant précis du 27/03/07 02:22, Berglas, Anthony s'exprimait en ces termes: > 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== > > Tomcat implements the J2EE security model, no more, no less. If you are developping web applications, you have 2 possibilities. Either you develop using this model (you limit access to ressources based on security-constraint), either you handle all the authentification stuff by yourself.
What seems you want to be able to do is having a public part (with a menu which display items depending on eventual current user's role) and a private part accessible only to some roles. Fine, the J2EE model can handle it easily. All you have to do is 1) have your code be able to handle cases where there is no current user (aka "anonymous") 2) Provide users with possibility to "login" via a simple url (eg. "/webapp-name/login") which has a security constraint that make it accessible to any logged in user (just have a common role for all user, let's name it hmmmm 'user') Now when user have logged in and browse the public part, their Principal object is kept, they are still logged-in and you can check their role. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
