Le 2012-02-02 à 11:05, Jesse Tayler a écrit :
> you mean you don't use the session to track use context?
I don't need a session for the WOWODC app, the only time the session is needed
is when someone submit a form, after that it's going stateless again.
I do store the session cookie in the cookie too, but I'm not doing anything
special with it.
> that's ok, I'm hip with that approach, but you still have a session object
> instantiated when users are clicking around right?
>
> so, basically, you're using javascript to rearrange your cookie from the
> component level?
>
> you are using a token cookie instead of the wosid style cookie?
>
> I'm not certain I'm following here --
>
>
> On Feb 2, 2012, at 10:58 AM, Pascal Robert wrote:
>
>> Just to be clear, I'm not using a session in that app, it's an auth cookie
>> that will work even if the app is restarted.
>>
>>> I'm doing this:
>>>
>>> <script>
>>> var token = '<wo:str value="$token" />';
>>> if ((!(undefined == token)) && (token != '')) {
>>> var c_value=escape(token) + "; path=/";
>>> document.cookie= "wowodcToken=" + c_value;
>>> window.location = '<wo:str
>>> value="$context.request.applicationURLPrefix" />';
>>> }
>>> </script>
>>>
>>> But yeah, we need something for WOForm so that it works in a REST context
>>> (e.g. so that it stays in /ra). That's one of the things to fix in ERRest.
>>>
>>>>
>>>> Ahh -- Ok, but what did you change?
>>>>
>>>> I'm moving to toward all ERD2W+ERRest so aside from forms, I'd like my
>>>> links to go to the /ra/ URL rather than the /wo/ URL
>>>>
>>>> Even if I get my sessions back, I'm wondering how I can get WOnder to use
>>>> the /ra/ URLs when possible?
>>>>
>>>>
>>>>
>>>> On Feb 2, 2012, at 10:45 AM, Pascal Robert wrote:
>>>>
>>>>> I had a similar problem with the WOWODC app. In my case, it's when a form
>>>>> is submitted, it's going back to the /wo handler since WOForm knows
>>>>> nothing about REST (can only use a direct action, so /wa, or stateful
>>>>> /wo). And like you, I had to change the cookie handling to get it to work.
>>>>>
>>>>>> yes, I was just noticing that I should add something like
>>>>>>
>>>>>> public String domainForIDCookies() {
>>>>>> return "/";
>>>>>> }
>>>>>>
>>>>>> unless my first test was wrong, that hasn't worked for me.
>>>>>>
>>>>>> but I'll keep trying, I have an unfortunate deployment turnaround time
>>>>>> situation going on here...have to modernize that for sure...
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 1, 2012, at 9:54 PM, George Domurot wrote:
>>>>>>
>>>>>>> This may be related to your Session.domainForIDCookies.
>>>>>>>
>>>>>>> You may need to override this (when !isDevelopmentMode()) — also,
>>>>>>> consider setting it to
>>>>>>> er.extensions.ERXApplication.replaceApplicationPath.replace.
>>>>>>>
>>>>>>> -G
>>>>>>>
>>>>>>> On Feb 1, 2012, at 6:11 PM, Michael Kondratov wrote:
>>>>>>>
>>>>>>>> I am having a same issue!!! It looks like session needs to be in URL
>>>>>>>> for wo to work.
>>>>>>>>
>>>>>>>> Michael Kondratov
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Feb 1, 2012, at 20:18, Jesse Tayler <[email protected]> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I just deployed ERRest with apache rules to shorten URLs
>>>>>>>>>
>>>>>>>>> I can't get sessions to stick.
>>>>>>>>>
>>>>>>>>> static pages /wa/ and /ra/ work as expected
>>>>>>>>>
>>>>>>>>> but session pages /wo/ show up but navigate back to Main page when
>>>>>>>>> clicking and there's no error, which seems like the session just
>>>>>>>>> isn't getting kept.
>>>>>>>>>
>>>>>>>>> Safari didn't let me check the cookies very well, or they moved the
>>>>>>>>> editor that used to be there...even firefox didn't seem to show me my
>>>>>>>>> cookie situation or I could not find it...
>>>>>>>>>
>>>>>>>>> Do I need to do something other than:
>>>>>>>>>
>>>>>>>>> setStoresIDsInURLs(false);
>>>>>>>>> setStoresIDsInCookies(true);
>>>>>>>>>
>>>>>>>>> To let the shortening work properly?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/michael%40aspireauctions.com
>>>>>>>>>
>>>>>>>>> This email sent to [email protected]
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/george%40boxofficetickets.com
>>>>>>>>
>>>>>>>> This email sent to [email protected]
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca
>>>>>>
>>>>>> This email sent to [email protected]
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca
>>>
>>> This email sent to [email protected]
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
