Re: Avoiding Cookies and JSESSION

[Sam Joseph <ga...@yha.att.ne.jp>]

Hi All,

Well I seem to have solved my problem. I created a new version of

org.apache.turbine.modules.actions.sessionvalidator.SessionValidator

that implemented the following method

public boolean requiresNewSession(RunData data)
{
return false;
}

thus allowing my phone to access the LogScreen without being forced to
supply a cookie.

I'd be interested to know what the logic behind the SessionValidator is,
and if I am creating a security hole my modifying the SessionValidator
in this way.

CHEERS> SAM

Sam Joseph wrote:

>Hi there,
>
>I am using turbine in an application where a very thin client (a phone)
>needs to send log reports back to the server. I created a screen called
>LogScreen that could be accessed without needing to be logged in and
>would only pass back a minimal amount of response. Perfect for logging
>from the phone.
>
>However it still creates a session id, sets a cookie, which means that
>the HTTP needs to be resubmitted with the cookie. This is difficult for
>the phone to do. Does anybody know if there is a simple way I can stop
>turbine from creating a session/setting a cookie for LogScreen?
>
>Does the main turbine servlet automatically create a session for every
>incoming connection?
>
>Thanks in advance.
>
>CHEERS> SAM
>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>  
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Avoiding Cookies and JSESSION

[Sam Joseph <ga...@yha.att.ne.jp>]

Bill Schneider wrote:

>Isn't there some way that Java servlets can create an HttpSession object for
>clients that don't support cookies?  I think there's a way you can supply
>the session ID as part of the URL.  (I think that's what the encodeURL and
>encodeRedirectURL do.)
>
Yes - and turbine seems to support that by appending a
;jsessionid=XXXXXXXXX to the end of the url, unfortunately for me
certain restrictions about the type of redirection taking place on the
phone mean that this URL rewriting could not solve my problem, but it
would certainly work for browsers with cookies switched off.

CHEERS> SAM


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>