There are only 5 ways to do authentification on a servlet application:

The first, FORM, use form that POST to /j_security_check the j_username
and the j_password

|web.xml:
<web-app>
  <login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
      <form-error-page>/Error.html
      </form-error-page>
      <form-login-page>/SignOn.html
      </form-login-page>
    </form-login-config>
</login-config>
</web-app>|

|html:
<form method="POST" action="j_security_check">
  <input type="text" name="j_username">
  <input type="password" name="j_password">
</form>|


The second and third, BASIC and DIGEST, use http protocol based
identification:

<web-app>
        <login-config>
                <auth-method>BASIC|DIGEST</auth-method>
                <realm-name>jpets</realm-name>
        </login-config>
</web-app>


The fourth use a ssl certificate client side

<web-app>
        <login-config>
                <auth-method>CLIENT-CERT</auth-method>
        </login-config>
</web-app>


And the fifth is to handle yourself all the work of authentification.
You lose container managed security, you must do more work to securize
your application but you can gain in flexibility.

In the first four ways, using container managed security, it's
impossible to attempt to force a login. It's when the user tries to
access a security protected url that the container redirect user to the
FORM or show the http login dialog or request the client SSL certificate.

PS: i agree with Olivier, don't put that damn password in the url!

olivier nouguier a écrit :
> I just like to point you the usual / standard use of J2EE
> authentication in
> a web tier !
>
> http://java.sun.com/products/servlet/download.html
>
> With restricted resources define in web.xml
> Login page (FORM)
> And a defined realm in context.xml (or server.xml)
>
> No more ...
>
> PS: I don't think it really smart to GET login & password in (clear)
> URL ;-)
>
>
> On 11/22/06, Santosh Puranshettiwar <[EMAIL PROTECTED]> wrote:
>>
>> olivier nouguier wrote:
>> Thanks.
>> > Hi
>> > The "natural" *post* should be
>> > http://localhost/realm-test
>> >>
>> >> /j_security_check?j_username=foo&j_password=bar
>> >
>> Let me make sure I got it right.
>>
>> So you mean the request should be something like this: -
>> URL: -
>> http://localhost/realm-test?j_security_check
>> (method=POST)
>> message body: -
>> j_username=foo&j_password=bar
>>
>> So appending a 'j_' will do the job?
>>
>> Also, in your case 'j_security_check' is the resource.
>> But in my case, *'RealmTestServetlet'* is the resource.
>> > And should be OK.
>> >
>> > What are your need ?
>> Till now, my authentication code used to be in the application layer.
>> But now, I wish to offload the task to my container (Tomcat) without any
>> changes to the
>> application protocol; which is to send username and password as _plain
>> key-value pairs_ in
>> the request URL.
>> >
>> >
>> > On 11/22/06, Santosh Puranshettiwar <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I wish to user a JDBCRealm with the username & password coming in the
>> >> HTTP request as key-value pairs.
>> >>
>> >> Is it possible?
>> >>
>> >> Elaborate: -
>> >> They request uri: -
>> >>
>> http://localhost/realm-test/RealmTestServetlet?username=foo&password=bar
>> >>
>> >> The Realm must authenticate with 'foo' & 'bar'.
>> >>
>> >> --
>> >> Santosh.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To start a new topic, e-mail: users@tomcat.apache.org
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>>
>> -- 
>> Santosh.
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to