Hi Mark,

if you are using the new window to show a PDF (which should not have any 
further links or buttons), it may be a better solution to use a direct action 
to show it and pass all necessary params to it.

C.U.CW
--
The three great virtues of a programmer are Laziness, Impatience and Hubris. 
(Randal Schwartz)

> On 27.11.2015, at 09:08, René Bock <[email protected]> wrote:
> 
> Hi Mark,
> 
> last week, we had a similar issue.  The problem was that, between two regular 
> POST requests, the client requested for ..../App.woa
> 
> 
> As noted in http://sourceforge.net/p/wonder/mailman/message/11756245/ 
> <http://sourceforge.net/p/wonder/mailman/message/11756245/> this request will 
> create a new session.
> 
> 
> Some "research" revealed, that
> 
>       WORequest._lookForIDsInCookiesFirst()
> 
> always will return false.  This seems the root cause of the problem. 
> Unfortunately, static methods can't overridden...
> 
> 
> Regards,
> 
>       René
> 
> 
>> Am 26.11.2015 um 23:29 schrieb Mark Wardle <[email protected] 
>> <mailto:[email protected]>>:
>> 
>> Thanks Chuck. I’m not sure. How can I check that? I haven’t got a favicon 
>> set presently. It shouldn’t default to accessing it via WO should it? I had 
>> thought it independent and a function of apache but of course, I do have a 
>> rewrite rule which redirects / to my WOA so it might well be doing that! Not 
>> entirely sure how to check or indeed fix!
>> 
>> Mark
>> 
>> 
>>> On 26 Nov 2015, at 22:25, Chuck Hill <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> Is your web server (or Wonder) protecting /favicon.ico from getting to your 
>>> app or handling it?  That request won’t contain the cookies (IIRC) which 
>>> results in a new session getting created and the app will return the cookie 
>>> from the new session (usually with an error response as it is not handling 
>>> the request.
>>> 
>>> Chuck
>>> 
>>> 
>>> From: <[email protected] 
>>> <mailto:[email protected]>> on 
>>> behalf of Mark Wardle <[email protected] <mailto:[email protected]>>
>>> Date: Thursday, November 26, 2015 at 2:18 PM
>>> To: Paul Hoadley <[email protected] <mailto:[email protected]>>
>>> Cc: webobjects-dev <[email protected] 
>>> <mailto:[email protected]>>
>>> Subject: Re: Odd backtracking error
>>> 
>>> Paul,
>>> 
>>> That sounds like what might be happening and explain the inconsistency 
>>> depending on, perhaps, the URL entered.
>>> 
>>> I’ll give it a go. Thank you!
>>> 
>>> Mark
>>> 
>>>> On 26 Nov 2015, at 22:16, Paul Hoadley <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>> Hi Mark,
>>>> 
>>>> On 27 Nov 2015, at 6:50 am, Mark Wardle <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>>> I’m getting a weird backtracking error. I have a component which mainly 
>>>>> uses component actions and one of these component actions uses 
>>>>> target=“_new” to show a PDF document in a new window.
>>>>> 
>>>>> The action uses
>>>>> WOResponse response = 
>>>>> WOApplication.application().createResponseInContext(context);
>>>>> to create a new response.
>>>>> 
>>>>> Sessions are stored in cookies.
>>>>> 
>>>>> On some computers (but not all), when one clicks the link, I get a login 
>>>>> page and in the log a session restoration error with no session. It works 
>>>>> fine on other computers running the same version of IE. I can’t reproduce 
>>>>> the problem at all on my development machine.
>>>>> 
>>>>> Any ideas?
>>>> 
>>>> I’m not sure this would explain everything you’re seeing here, but you can 
>>>> get session loss (and the resulting unexpected bounce to a login page) 
>>>> when using cookies for session ID storage if 
>>>> WOSession.domainForIDCookies() is returning something “too specific” for 
>>>> your deployment setup. By default, that method returns the application’s 
>>>> full path, right down to the “.woa” extension. So, for example, if you’re 
>>>> using URL re-writing in deployment, there could easily be a mismatch. I 
>>>> usually override it to return “/”. Again, not sure it explains everything 
>>>> you’re seeing there, but it’s something to rule out.
>>>> 
>>>> 
>>>> --
>>>> Paul Hoadley
>>>> http://logicsquad.net/ <http://logicsquad.net/>
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      ([email protected] 
>> <mailto:[email protected]>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/bock%40salient.de 
>> <https://lists.apple.com/mailman/options/webobjects-dev/bock%40salient.de>
>> 
>> This email sent to [email protected]
> 
> --
> salient doremus
> 
> salient GmbH
> Kontorhaus -  Lindleystraße 12
> 60314 Frankfurt Main
> 
> Fon +49 (0)69 - 650096 -0, Durchwahl: - 18, Fax: -70
> 
> http://www.salient.de <http://www.salient.de/>
> http://www.doremus.com
> http://www.openforms.de
> 
> Geschäftsführer: Peter Biler, Alexander Gerling, Lars Ohlerich
> Amtsgericht Frankfurt Main, HRB 48693
> 
> // Neuer Schwung auf allen Endgeräten für den Automobilclub von Deutschland: 
> http://www.avd.de/ <http://www.avd.de/>
> _______________________________________________
> 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/cw%40i4innovation.de
> 
> This email sent to [email protected]

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

 _______________________________________________
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]

Reply via email to