>>1) Provide a login page. Every membership-oriented site on
>>the internet
>>provides a login form on their front page (e.g. www.aol.com,
>>www.hotmail.com). Form-based login only lets you
>>authenticate when you
>>transition to a protected page.
You can get around this issue by having your login page actually be that front page
and have it initially invoked.
>>2) Allow the user to try again on the "bad password" page. The user
>>must hit "back" on their browser (or click on another link that takes
>>them to the protected page).
And this one by having the "bad password" page to be that same page.
The user won't know what is going on behind the scenes.
>>Umm, maybe because J2EE security services SUCK? :-)
That is a bold statement considering security is one of the key features of J2EE.
I am curious to hear others opinions on this issue.
Chris
>>-----Original Message-----
>>From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, January 31, 2001 5:18 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: Is LoginServlet bad practice?
>>
>>
>>Umm, maybe because J2EE security services SUCK? :-)
>>
>>Somebody didn't really think out the specification very well.
>>Form-based login is a step up from boring old http authentication, but
>>it doesn't go nearly far enough. You can't:
>>
>>1) Provide a login page. Every membership-oriented site on
>>the internet
>>provides a login form on their front page (e.g. www.aol.com,
>>www.hotmail.com). Form-based login only lets you
>>authenticate when you
>>transition to a protected page.
>>
>>2) Allow the user to try again on the "bad password" page. The user
>>must hit "back" on their browser (or click on another link that takes
>>them to the protected page).
>>
>>The form-based login might work ok for an e-commerce app, where
>>authentication is only required on the transition to the
>>checkout page,
>>but the web is a lot more than just that. This deficiency in the j2ee
>>spec is the only reason I have any server-dependent code in my app at
>>all.
>>
>>Jeff
>>
>>>-----Original Message-----
>>>From: Dave Wolf [mailto:[EMAIL PROTECTED]]
>>>Sent: Wednesday, January 31, 2001 9:28 AM
>>>To: [EMAIL PROTECTED]
>>>Subject: Re: Is LoginServlet bad practice?
>>>
>>>
>>>But why write a line of code when J2EE security services
>>>provide this all to
>>>you.
>>>
>>>Dave Wolf
>>>Internet Applications Division
>>>Sybase
>>>
>>>----- Original Message -----
>>>From: "Rahman, Zahid" <[EMAIL PROTECTED]>
>>>To: <[EMAIL PROTECTED]>
>>>Sent: Wednesday, January 31, 2001 12:03 PM
>>>Subject: Re: Is LoginServlet bad practice?
>>>
>>>
>>>> Not my opinion,
>>>>
>>>> With regard to internal staff changing the servlet ?
>>>>
>>>> For instance what you are going to do if the staff take
>>you physical
>>>machine
>>>> then what you going to do ?
>>>>
>>>> Interesting point though. Not much you can do when the
>>>servlet methods are
>>>> specified and common to all servlets Not much you can do ?
>>>>
>>>> The key point here is internal staff changing code ?
>>>>
>>>> Regards
>>>> Zahid
>>>> > -----Original Message-----
>>>> > From: Bono, Chris [SMTP:[EMAIL PROTECTED]]
>>>> > Sent: Wednesday, January 31, 2001 3:30 PM
>>>> > To: [EMAIL PROTECTED]
>>>> > Subject: Re: Is LoginServlet bad practice?
>>>> >
>>>> > Why not use J2EE security?
>>>> >
>>>> > -----Original Message-----
>>>> > From: Carlos Otero Barros [mailto:[EMAIL PROTECTED]]
>>>> > Sent: Wednesday, January 31, 2001 8:31 AM
>>>> > To: [EMAIL PROTECTED]
>>>> > Subject: Is LoginServlet bad practice?
>>>> >
>>>> >
>>>> > Hi All!
>>>> >
>>>> > Recently I have been envolved in a discussion about the
>>>convenience of
>>>> > encapsulating login process in a separate servlet. Namely
>>>LoginServlet.
>>>> > My opinion is this is a bad practice from a security
>>point of view.
>>>> > Internal personel could substitute the LoginServlet with
>>any other
>>>> > simple servlet with the same methods() and take the
>>whole web site
>>>> > unsecured.
>>>> >
>>>> > Your opinion?
>>>> >
>>>> > Thanks
>>>> >
>>>> >
>>>===============================================================
>>>===========
>>>> > =
>>>> > To unsubscribe, send email to [EMAIL PROTECTED] and
>>>include in the
>>>> > body
>>>> > of the message "signoff EJB-INTEREST". For general help,
>>>send email to
>>>> > [EMAIL PROTECTED] and include in the body of the
>>>message "help".
>>>> >
>>>> >
>>>===============================================================
>>>===========
>>>> > =
>>>> > To unsubscribe, send email to [EMAIL PROTECTED] and
>>>include in the
>>>> > body
>>>> > of the message "signoff EJB-INTEREST". For general help,
>>>send email to
>>>> > [EMAIL PROTECTED] and include in the body of the
>>>message "help".
>>>>
>>>>
>>>===============================================================
>>>============
>>>> To unsubscribe, send email to [EMAIL PROTECTED] and
>>>include in the
>>>body
>>>> of the message "signoff EJB-INTEREST". For general help,
>>>send email to
>>>> [EMAIL PROTECTED] and include in the body of the
>>message "help".
>>>>
>>>>
>>>
>>>===============================================================
>>>============
>>>To unsubscribe, send email to [EMAIL PROTECTED] and
>>>include in the body
>>>of the message "signoff EJB-INTEREST". For general help,
>>send email to
>>>[EMAIL PROTECTED] and include in the body of the message "help".
>>>
>>>
>>
>>==============================================================
>>=============
>>To unsubscribe, send email to [EMAIL PROTECTED] and
>>include in the body
>>of the message "signoff EJB-INTEREST". For general help,
>>send email to
>>[EMAIL PROTECTED] and include in the body of the message "help".
>>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
