/**
* Overidden to handle requests with expired session made while refusing new sessions. See responseForRefusedRequest() for details. This is here, rather than in GVCSMCore as it does not work for session
IDs stored in the URL which is what GVCSMAdmin uses.
*/
public WOResponse dispatchRequest(WORequest request)
{
WOResponse result;
// Don't handle requests with expired sessions when refusing sessions.
// Requests where request.sessionID() == null are probably from JavaMonitor
// and should be processed normally.
String sessionID = request.sessionID();
if (isRefusingNewSessions() &&
(sessionID !=
null) &&
(sessionStore().restoreSessionWithID(sessionID, request) ==
null))
{
DebugOut.println(1, "Refusing new Sessions and request has session ID that is expired or from foreign instance: " + request.sessionID());
DebugOut.println(1,
"Requested uri: " + request.uri());
result = responseForRefusedRequest();
}
else
{
result =
super.dispatchRequest(request);
}
return result;
}
/**
* If the woadaptor sees a session ID / instance number in a request it will send the request to an instance even if that instance is refusing new requests and the session has expired (or was from a previous
run of that instance). This is because the adaptor has no way of knowing if the session has expired. This results in new sessions getting created when Refuse New Sessions is On. We can see this in the application log:
<br><br>
* <pre>
* [2002-08-26 16:36:52 EDT]
<WorkerThread16>
<WOApplication> !!! _initializeSessionInContext: called with refuseNewSessions set !!!
* </pre><br><br>
* This can result in the application taking a long time to shut down as new session can be created as long as all users do not close their browsers. This method handles this situation by expiring the
wosid and
woinst cookies and then having the browser reload the page. When the request is made the second time it will not have any session ID or instance number and so will be directed to a non-refusing instance, if any.<br>
* <br>
* <b>NOTE</b>: This ONLY works if the sessionID is stored in cookies and not in the URL! It can be extended to handle this.
*
* @return WOResponse with expired
wosid and woinst cookies and a content of a 1 second meta refresh so that the URL is re-requested.
*/
protected WOResponse responseForRefusedRequest()
{
DebugOut.println(1,
"Creating response...");
WOResponse result =
new WOResponse();
// Create
wosid and woinst cookies in the far past so that they will be removed from the user's browser.
NSTimestamp dateInPast = (new NSTimestamp()).timestampByAddingGregorianUnits(-10, 0, 0, 0, 0, 0);
WOCookie wosidCookie =
new WOCookie("wosid",
"refused", "/",
null, dateInPast,
false);
WOCookie woinstCookie =
new WOCookie("woinst",
"-1", "/",
null, dateInPast,
false);
// Have to do this instead of calling addCookie() as cookies() is not copied into the headers outside of the R-R loop.
NSMutableArray killedCookies =
new NSMutableArray(2);
killedCookies.addObject(wosidCookie.headerString());
killedCookies.addObject(woinstCookie.headerString());
result.setHeaders(killedCookies,
"set-cookie");
// Have to use a meta refresh instead of a redirect as NS 4.7 chokes (just sits spinning) when redirected to the same URL that it had requested. Other browsers do not exhibit this problem.
result.setContent("<html><head><meta HTTP-EQUIV=\"Refresh\" CONTENT=\"1\"></head><body></body></html>");
result.setHeader("text/html",
"content-type");
result.setStatus(300);
result.disableClientCaching();
result.setHTTPVersion("HTTP/1.1");
return result;
}
On 2015-05-27, 1:58 PM, "Paul Hoadley" wrote:
On 28 May 2015, at 12:35 am, Chuck Hill <
email@hidden> wrote:
If someone has a bookmark or a cookie with the instance number in it, that will override Refuse New Sessions.
Ah right, that’s it then. Looks like there are some robots that have picked up some URLs from the front page containing instance numbers. (Put a robots.txt at the root about 12 hours ago—looks like Google is honouring that, Baidu isn’t. Great.)