| Thank you for all of the replies relating to this. I had used a direct action but was getting the same problem and do think it might relate to not picking up the cookie properly. It is difficult to test as it doesn’t happen on all machines - only some specific Windows 7/IE clients in a particular room - so I’m going to try adding a wosid manually and seeing how that goes in testing. Alternatively, I might switch to storing the session id in the url rather than a cookie.
Best wishes, Mark On 27 Nov 2015, at 08:27, CHRISTOPH WICK | i4innovation GmbH, Bonn < email@hidden> wrote:
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)
Hi Mark,
last week, we had a similar issue. The problem was that, between two regular POST requests, the client requested for ..../App.woa
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é
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
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
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@hidden> wrote:
Hi Mark,
On 27 Nov 2015, at 6:50 am, Mark Wardle < email@hidden> 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.
// Neuer Schwung auf allen Endgeräten für den Automobilclub von Deutschland: http://www.avd.de/
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|