This follows on from yesterday's discussion about whether in my application, I can have more than one page with an embedded login form or not.
I've been looking over the servlet spec (V2.2) and it seems that I can't actually do this which is a shame. So I'm now looking at a more conventional log in from a login page. But can anyone explain to me why I dont see my login page when I run the application? Login.jsp contains the following: <form action = "<c:url value = 'j_security_check' />" method = "post"> <table align = "center" border = "0" cellspacing = "0"> <tr> <th align = "right"><font class = "label">Username</font></th> <td align = "left"><input class = "textInput" name = "j_username" type = "text"></td> </tr> <tr> <th align = "right"><font class = "label">Password</font></th> <td align = "left"><input class = "textInput" name = "j_password" type = "password"></td> </tr> <tr> <td></td> <td> <input class = "button" type = "submit" value = "Log in"> <input class = "button" type = "reset" value = "Clear"> </td> </tr> </table> </form> Which corresponds to the following in web.xml: <welcome-file-list> <welcome-file>/jsp/about/concept.jsp</welcome-file> </welcome-file-list> <security-constraint> <display-name>Security Constraint</display-name> <web-resource-collection> <web-resource-name>myApp</web-resource-name> <description/> <url-pattern>/aboutConcept</url-pattern> </web-resource-collection> <auth-constraint> <description/> <role-name>ADMIN</role-name> </auth-constraint> <user-data-constraint> <description/> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint > <login-config> <auth-method>FORM</auth-method> <realm-name>Form-Based Authentication Area</realm-name> <form-login-config> <form-login-page>/jsp/security/protected/login.jsp</form-login-page> <form-error-page>/jsp/security/protected/error.jsp</form-error-page> </form-login-config> </login-config> <security-role> <description/> <role-name>ADMIN</role-name> </security-role> But when I run the application, all I get is the html of the page specified in the welcome file list? But if I then invoke a link from the welcome file, I get the login page. Surely it should be the other way around? -----Original Message----- From: André Warnier [mailto:a...@ice-sa.com] Sent: 04 Oct 2011 19 56 To: Tomcat Users List Subject: Re: Using multiple login pages app...@dsl.pipex.com wrote: > Not sure about which version of security I will use but I would like > to accommodate MD5 verification into things. There's no sensitive or > confidential info in the system either so protected page access may not be required. > I don't know what you have in mind, but there are some basic principles to avoid wasting your time : 1) In Tomcat (and other servlet engines), there are 2 different ways of doing authentication : - declarative, as per web.xml. In that case Tomcat, /before it evens calls the webapp or any filter in it/, intercepts a non-authenticated call and returns *the* login form to the browser. It then (later) intercepts the submit of that form by the browser, checks the credentials, and if they pass muster, it allows the call to proceed to the webapp which the user wanted in the first place. - application- or filter-based authentication : in this case, Tomcat is not aware that there is an authentication taking place. It forwards the call to the webapp, and a filter /in the webapp/ intercepts the call and does whatever is needed to check the authentication, return a login form etc.. This second authentication scheme is probably more flexible for doing the kind of thing you seem to want to do (but also more complex to do). 2) There already exist a number of authentication systems on the market. Unless this is considered as an exercise, re-use an existing one instead of rolling you own. Web authentication looks deceptively simple, but is in fact quite complex and delicate, and open to many mistakes which completely defeat the purpose. (This being said, if it is an exercise, it is an interesting area). 3) anything that your server sends to a browser should be considered "open and lost". Once you send something out there, the recipient can do with it what he wants : save it, analyse it, copy it, decompile it, falsify it, re-send it to your server and whatnot. There is no practical way to avoid that. (You don't even know that it is really a browser out there). 4) the only good way to secure things if you do form authentication, is to work over HTTPS. The customer is going to type a login-id and a password, in the form, in clear. The browser is going to send this over HTTP to the server. Anyone who can "sniff" this traffic is going to see what is sent. And even if he does not understand it, he can record it and replay it. But not under HTTPS. 5) users always take the easy path. That means that, if they can choose their password, they will pick the same one as the one they use already for their network login, for their email account, for their bank account, etc.. So if anyone subverts /your/ login system - even if on /your/ server there is nothing vital to grab - the damage is probably not limited to your server. You don't want to be accused of facilitating the bad guy's job. 6) If you are thinking of encrypting the data in the browser, it's probably not worth the effort. For that, you will have to write some special code, and download it to the browser to run it there. Once you do that, it can be saved, analysed, replicated, falsified, disabled. So why bother ? HTH. Been there, etc.. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org