The forms for container managed security don't have to be plain html - you
can configure in the web.xml custom "Logon" and "Logon Error" pages which
can be jsps, not just plain html. I have a custom tag on each of these pages
which writes the fact that a user has arrived at that page to log4j along
with details from the request (e.g. IP address). Log4j is pretty powerful in
how you can configure it to filter that info and where to send it to.
There are tags in the Jakarta Taglibs which you could use to achieve the
same thing...
http://jakarta.apache.org/taglibs/doc/log-doc/intro.html
http://jakarta.apache.org/taglibs/doc/request-doc/intro.html
For example on your "Logon Error Page", you might have something like
this...
<req:request id="req"/>
<log:error category="myapp.logon.failed">
<bean:write name="req" property="remoteAddr"/>
<bean:write name="req" property="remoteHost"/>
</log:error>
Once a user has "logged on", you can get the user name from from the request
and then look up the user details wherever they are stored...
request.getUserPrincipal().getName()
The actual form elements required are, as you say, plain html - but is there
any need for special tags since the action your posting to is fixed?
Niall
----- Original Message -----
From: "Tim Christopher" <[EMAIL PROTECTED]>
Sent: Tuesday, February 08, 2005 2:08 AM
> I've recently discovered that it is not possible to map an action to
> j_security_check. Given this situation how is it possible to populate
> a form bean with user data, or create a log of any failed login
> attempts (bad username / password) if the container takes control of
> the entire login process?
>
> Looking back at previous posts to the newsgroup I can see that in the
> past people have just used plain html to produce the j_security_check
> form. Is it possible to do this using the <sslext:form> tag, but so
> that it does not require a Struts action mapping for j_security_check
> to be present?
>
> I was currently intending on using JDBCRealm and the security-filter
> to control the site's security, though given the above problems I'm
> starting to think there might be a better way? Or are these problems
> everyone has already solved, as surely some form of login system is
> present in the vast majority of Struts applications.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
