tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rpr_listas <>
Subject Re: Form authentication with captcha...
Date Thu, 05 Jul 2007 08:50:10 GMT
Hi David,

I don't like realm because I don't want to implement a new 
authentication repository, I only want to implement a new authentication 
method. Doing this at the realm level limit the possibilities of the 
form, i want to do captcha validation when the user has has tw 
consecutive errors from the same IP. How realm can access this data?

Thanks in advance.

David Delbecq escribió:
> En l'instant précis du 04/07/07 10:15, rpr_listas s'exprimait en ces
> termes:
>> Hello David,
>> I know that this is out of the specification, and bind my application
>> to this server implementation, but modify the realm has the same
>> problem, transform my application in a tomcat-only application.
> Indeed it would make your application work only with server
> authentification that split password in 2 parts (password/captcha), but
> 1) it's easier to make and maintain a custom realm accros tomcat version
> than patch tomcat authentificator.
> 2) if you need to switch later from tomcat to jboss or other container,
> all you have is to recode for that server an equivalent of your realm
> (most server provide such support for user authentifications), while
> doing a fix similar to the one of authentificator might prove more
> difficult as not an expected point of extension.
> 3) If you limit change to realm, other webapplications can still run
> without trouble on your tomcat, this include the tomcat manager, tomcat
> admin, that are commonly deployed on tomcat.
>> Build a custom authentication is not solution, because this disconnect
>> the application from the J2EE standard, and I prefer to fit to
>> standards in the rest of the application. I think that the better
>> approach could be a custom authentication servlet and this servlet
>> store a new Principal in the container. But i think that in J2EE can't
>> access to do this from servlet.
> Indeed it can't really do it, but you could perhaps use and
> authentification filter like this:
> There is even a discussion on how to pass additional arguments to it's
> authentification mecanism:
>> Best regards.
>> Ricardo
>> David Delbecq escribió:
>>> Hello,
>>> Form authnetificator does form based authentification regarding the
>>> corresponding J2EE specifications, which specify the submit name of the
>>> username field (j_username), the submit name of the user password
>>> (j_passwrd), and that's all. Of course you, developper of webapplication
>>> can customize form (adding company logo, etc), but the specs states that
>>> user must provide username and password and submit it to
>>> /j_security_check url. Adding a captcha in this specs or other
>>> informations is not possible like that.
>>> The only 2 ways i see to add captcha and not break specs is either
>>> 1) to create a realm that expect the captcha to be appended or perpended
>>> to password.
>>> eg:
>>> j_username: johnSmith
>>> j_password: 12345@captcha=AdQ1
>>> The realm could probably compare the provided captcha with some value
>>> stored somewhere else
>>> the j_password field could be constructed, client side, with javascript,
>>> from 2 not submitted fields.
>>> or
>>> 2) Don't rely on container security and provide your own security with
>>> you own whatever forms.
>>> En l'instant précis du 03/07/07 10:45, rpr_listas s'exprimait en ces
>>> termes:
>>>> Hi all!
>>>> I'm thinking in implement a captcha
>>>> ( protection for web-based
>>>> authentication. I'm looking in the tomcat surce and the form
>>>> authentication seems be implemented by
>>>> org.apache.catalina.authenticator.FormAuthenticator class.  But I'm
>>>> not sure if change this class is the right way.
>>>> Are there other better method to do this?
>>>> Must I change the FormAutenticator class or must extend it in other
>>>> class and i can refer to it in the tomcat configuration ?
>>>> Thanks in advance and best regards.
>>>> Ricardo.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message