Running more than one WO application on the same domain with the session and instance cookie paths set to "/" definitely brings complications. We only do it because for two applications we want to expose 'user friendly' URLs using Apache rewrite rules. As Ben mentions, because the adaptor matches the instance cookie name based on a substring, you need to be really careful that your new cookie name does not contain the string "woinst". It may even appear to work but the application is likely to be using the instance cookie for the other app or apps.
We are using a rewrite condition and rule to read in the cookie, get the instance number and put it into the request URL. This works because the adaptor takes instance IDs from the URL in preference to the cookie. The rewrite idea comes from this blog: http://tgwbd.org/blog/2009/11/01/the-duke-of-url-part-3/ and looks like this: RewriteCond %{HTTP_COOKIE} custom_ins=([-0-9][0-9]*) RewriteRule ^/friendlyUrl/(.*)/?$ /cgi-bin/WebObjects/<AppName>.woa/%1/$1/ [PT,L] There still seems to be a problem with component actions though, because if the component request handler sees the instance ID in the URL, but no session ID, it messes up the parsing of the URL because it is looking for a component name in the URL. I guess we could solve this by subclassing the request handler or creating a more sophisticated rewrite rule to handle session IDs too. Anyway, *beware* when overriding WO's session and instance cookie stuff: WOSession.domainForIDCookies(), WOApplication.instanceIdKey() and WOApplication.sessionIdKey(). -- James On 9 Sep 2010, at 17:15, Lawson, Ben wrote: > You're right of course Chuck, turns out our instanceIdKey had a trailing > "woinst". The "woinst" value is looked up in the cookie header by doing a > string match, so as long as you have "woinst" appended to the cookie name in > the Application class it works fine. This of course becomes problematic when > you have multiple applications storing IDs in cookies under similar paths (or > really, any other session creating application with a less specific path). > > We'll have to get around it with some re-writes, not so awful and at least we > know what was biting us now. > > Thanks, > -Ben > > On Sep 9, 2010, at 4:58 PM, Chuck Hill wrote: > >> I played with this a while ago and my experience was that it did NOT work. >> It appears to work, but something else was causing this. I don't recall >> what, maybe everything hitting instance 1? I just recall thinking that it >> was working and wondering why for quite a while before noticing that it was >> in fact not really working. >> >> I think the API for renaming woinst is just wrong (wrong as in can not and >> does not work). Renaming wosid does work. >> >> Chuck >> >> On Sep 9, 2010, at 7:47 AM, Lawson, Ben wrote: >> >>> Hi List, >>> >>> A strange question sure, but for curiosity's sake I'm trying to understand >>> how the WebObjects adaptor maintains a mapping of instance ID cookie names >>> to applications. Looking at the source it looks like "woinst" is hardcoded >>> into the adaptor in config.h, and I can't find anywhere else the >>> INST_COOKIE var is set. Then in _collectRequestInformation in transaction.c >>> the cookie header is searched for the INST_COOKIE value ("woinst") to >>> determine which app instance to send the request to >>> (_collectRequestInformation writes to memory the app instance specified for >>> the handleRequest function to look up later). >>> >>> So I'm left wondering how the adaptor knows where to fetch the the instance >>> ID from to forward requests to. I can see that it works, requests that >>> create sessions with a custom instanceIdKey continue to find their way to >>> the correct application instance, but why? Obviously I'm missing something, >>> would love a hand figuring out what! >>> >>> -Ben >> >> >> -- >> Chuck Hill Senior Consultant / VP Development >> >> Practical WebObjects - for developers who want to increase their overall >> knowledge of WebObjects or who are trying to solve specific problems. >> http://www.global-village.net/products/practical_webobjects >> >> >> >> >> >> >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/jbrook%40upcbroadband.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: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
