Skip to main content

Re: [webtier] Cookieless form based authentication

1 reply [Last post]
Anonymous

webtier@javadesktop.org wrote:

> Is this possible with glassfish?

No, this is not supported.

GlassFish stores information about the original request in a session, so
that the original request may be restored from the session and resumed
once authentication has succeeded.

If cookies were disabled, the form's login page would have to be
rewritten (by encoding the session id in the URL of the form's action
attribute) before returning it to the user, which would be difficult if
not impossible.

Jan

> Basically, I need to display "protected" data in Google Earth, but GE
> does not support cookies, even within an iframe.
> Other details about what I'm doing: The user would be logged in to
> the webapp in a browser window. They would then click a link/button
> which would cause a KML file to be downloaded and opened by GE. The
> placemarks that end up in GE will have links/buttons within their
> descriptions that cause changes to the web app running in the original
> browser. I would like this functionality to be protected, obviously.
> Any suggestions??
> -ds
> [Message sent by forum member 'digitalseraphim']
>
> http://forums.java.net/jive/thread.jspa?messageID=394526
>
> ---------------------------------------------------------------------
> 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.
digitalseraphim
Offline
Joined: 2008-04-30

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* :^)

-ds