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
