Skip to main content

Re: [webtier] Cookieless form based authentication

2 replies [Last post]
Anonymous

webtier@javadesktop.org wrote:
> Couldn't this be a requirement to use this form of authentication? The developer would know that this would/could be possible, and could set the action to "/j_security_check?jsessionid=${session.id}" to pass the session information along.
>
> Another idea: Why can't the session id be passed along as a hidden form input? Again, the developer would have to add a tag to the login form, but this is trivial. We already have to use specific names for the username and password fields, why not one more?
>
> I feel like I'm being a little bit snappy, and if I'm coming across that way, I apologize. It just seems like with this project I'm working on, every time I get a "good idea", I run into a "shortcoming" of the tool that I'm using.
>
> Am I totally off base with these thoughts? Is there something flawed with my thinking? *sigh* :^)
>

I love your idea. :)

As for appending the jsessionid to the action URL, the developer could
make this conditional, depending on whether URL rewriting was enabled
for the particular application, by querying the "application" variable
(of type ServletContext) for its effective session tracking modes (by
calling the new ServletContext#getEffectiveSessionTrackingModes that was
added in Servlet 3.0), provided the login page is of type JSP.

The hidden input field approach would work in either case.

I think it is time to rewrite or remove the following paragraph from the
Servlet spec, whose Section 13.6.3.1 ("Login Form Notes") currently reads:

Form based login and URL based session tracking can be problematic to
implement.
Form based login should be used only when sessions are being
maintained by cookies or by SSL session information.

This paragraph has been around for the longest time I think.

Jan
> -ds
> [Message sent by forum member 'digitalseraphim']
>
> http://forums.java.net/jive/thread.jspa?messageID=394636
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jan Luehe

Jan Luehe wrote:
> webtier@javadesktop.org wrote:
>> Couldn't this be a requirement to use this form of authentication?
>> The developer would know that this would/could be possible, and could
>> set the action to "/j_security_check?jsessionid=${session.id}" to
>> pass the session information along.
>> Another idea: Why can't the session id be passed along as a hidden
>> form input? Again, the developer would have to add a >> type="hidden" name="jsessionid" value="${session.id}" /> tag to the
>> login form, but this is trivial. We already have to use specific
>> names for the username and password fields, why not one more?
>>
>> I feel like I'm being a little bit snappy, and if I'm coming across
>> that way, I apologize. It just seems like with this project I'm
>> working on, every time I get a "good idea", I run into a
>> "shortcoming" of the tool that I'm using.
>>
>> Am I totally off base with these thoughts? Is there something flawed
>> with my thinking? *sigh* :^)
>>
>
> I love your idea. :)
>
> As for appending the jsessionid to the action URL, the developer could
> make this conditional, depending on whether URL rewriting was enabled
> for the particular application, by querying the "application" variable
> (of type ServletContext) for its effective session tracking modes (by
> calling the new ServletContext#getEffectiveSessionTrackingModes that
> was added in Servlet 3.0), provided the login page is of type JSP.

If you appended the session id to the login form's j_security_check
action URL, then no changes to the container would be required, right?

Have you tried it?

Thanks,

Jan
>
> The hidden input field approach would work in either case.
>
> I think it is time to rewrite or remove the following paragraph from
> the Servlet spec, whose Section 13.6.3.1 ("Login Form Notes")
> currently reads:
>
> Form based login and URL based session tracking can be problematic to
> implement.
> Form based login should be used only when sessions are being
> maintained by cookies or by SSL session information.
>
> This paragraph has been around for the longest time I think.
>
>
> Jan
>> -ds
>> [Message sent by forum member 'digitalseraphim']
>>
>> http://forums.java.net/jive/thread.jspa?messageID=394636
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

digitalseraphim
Offline
Joined: 2008-04-30

I can't remember if I did or not, but there is a problem that I realized last night, but I'm just finally able to get to posting it. The session that is used is the one that is "created" for the original, protected asset request. A redirect is sent to the browser (with a cookie) telling them to go to the form page. This is the step where the container would have to be changed. Once the form is being "processed" within the right session, we would be all set, however, currently, there is no way to do it without setting a cookie. I think this might be possible... will check when I get back to my sample code.

-ds