Fwd: Re: Re: Re: Cookie forwarding

>> So, because Orbeon Forms does not forward my own cookies I cannot  
>> test
>> browser support for cookies in that way. And by checking whether or  
>> not
>> cookies are forwarded at all does not make work because Orbeon  
>> Forms sends
>> a mysterious JSESSIONID cookie always along with the submitted POST
>> request if it has been triggered using the xforms-ready event.
>>
>
> Looks like my previous message wasn't clear enough: the point of the  
> method
> I was suggesting is not to check wether the JSESSIONID is there or  
> not, but
> to check if something you stored in the session is there or not. If  
> cookies
> are not supported, if on a subsequent request you try to read from the
> session, a new session will be created and you won't be able to find  
> what
> you just stored in a previous request. Does this make sense?

> Hi Alex,
>
>
> Getting back to this old issue that I had--and still have--with  
> cookies.
>
>>> So, because Orbeon Forms does not forward my own cookies I cannot  
>>> test
>>> browser support for cookies in that way. And by checking whether  
>>> or not
>>> cookies are forwarded at all does not make work because Orbeon  
>>> Forms sends
>>> a mysterious JSESSIONID cookie always along with the submitted POST
>>> request if it has been triggered using the xforms-ready event.
>>>
>>
>> Looks like my previous message wasn't clear enough: the point of  
>> the method
>> I was suggesting is not to check wether the JSESSIONID is there or  
>> not, but
>> to check if something you stored in the session is there or not. If  
>> cookies
>> are not supported, if on a subsequent request you try to read from  
>> the
>> session, a new session will be created and you won't be able to  
>> find what
>> you just stored in a previous request. Does this make sense?
>
> That does make sense. However, my Web application uses URL rewriting  
> technique as an alternative option for keeping track of the session  
> if cookies have been disabled on the browser. Therefore, this  
> approach does not work for me. I was able to find an attribute  
> (which was set to the session when handling the GET request) from  
> the session when handling the subsequent POST request.
>
> I may have an idea where the problem is, though. I have a  
> dynamically generated XForms document, which contains a POST  
> submission. In test #1, the POST submission is triggered using a  
> button. When cookies are enabled the servlet which handles the POST  
> submission finds the JSESSIONID cookie. When cookies are disabled  
> the servlet does not find any cookies (finds the test attribute from  
> the session, though) as expected.
>
> In test #2, the POST submission is triggered using the xforms-ready  
> event. When cookies are enabled the servlet which handles the POST  
> submission also finds the JSESSIONID cookie. However, when cookies  
> are disabled the servlet finds the JSESSIONID cookie (and the test  
> attribute from the session) even though it should not, right?!?! The  
> only difference in the tests was that in test #1 the POST submission  
> was manually triggered using a button and in test #2 the POST  
> submission was automatically triggered using the xforms-ready event.  
> Shouldn't the end result be the same despite the way how the POST  
> submission is triggered?
>
> Kind regards
>
>
> -Markku
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

> Markku,
>
> I haven't gone back up this thread to see the original issue, but I  
> thought I would mention that we recently implemented server-side  
> session (cookie) handling for submissions:
>
> http://wiki.orbeon.com/forms/doc/developer-guide/configuration-properties#TOC-HTTP-client-state-setup
>
> -Erik
>
> On Jul 15, 2009, at 6:45 AM, Markku Laine wrote:
>
>> Hi Alex,
>>
>>
>> Getting back to this old issue that I had--and still have--with  
>> cookies.
>>
>>>> So, because Orbeon Forms does not forward my own cookies I cannot  
>>>> test
>>>> browser support for cookies in that way. And by checking whether  
>>>> or not
>>>> cookies are forwarded at all does not make work because Orbeon  
>>>> Forms sends
>>>> a mysterious JSESSIONID cookie always along with the submitted POST
>>>> request if it has been triggered using the xforms-ready event.
>>>>
>>>
>>> Looks like my previous message wasn't clear enough: the point of  
>>> the method
>>> I was suggesting is not to check wether the JSESSIONID is there or  
>>> not, but
>>> to check if something you stored in the session is there or not.  
>>> If cookies
>>> are not supported, if on a subsequent request you try to read from  
>>> the
>>> session, a new session will be created and you won't be able to  
>>> find what
>>> you just stored in a previous request. Does this make sense?
>>
>> That does make sense. However, my Web application uses URL  
>> rewriting technique as an alternative option for keeping track of  
>> the session if cookies have been disabled on the browser.  
>> Therefore, this approach does not work for me. I was able to find  
>> an attribute (which was set to the session when handling the GET  
>> request) from the session when handling the subsequent POST request.
>>
>> I may have an idea where the problem is, though. I have a  
>> dynamically generated XForms document, which contains a POST  
>> submission. In test #1, the POST submission is triggered using a  
>> button. When cookies are enabled the servlet which handles the POST  
>> submission finds the JSESSIONID cookie. When cookies are disabled  
>> the servlet does not find any cookies (finds the test attribute  
>> from the session, though) as expected.
>>
>> In test #2, the POST submission is triggered using the xforms-ready  
>> event. When cookies are enabled the servlet which handles the POST  
>> submission also finds the JSESSIONID cookie. However, when cookies  
>> are disabled the servlet finds the JSESSIONID cookie (and the test  
>> attribute from the session) even though it should not, right?!?!  
>> The only difference in the tests was that in test #1 the POST  
>> submission was manually triggered using a button and in test #2 the  
>> POST submission was automatically triggered using the xforms-ready  
>> event. Shouldn't the end result be the same despite the way how the  
>> POST submission is triggered?
>>
>> Kind regards
>>
>>
>> -Markku
>>
>>
>>
>>
>> --
>> You receive this message as a subscriber of the [hidden email]  
>> mailing list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws