Actually, there is not a problem with component action URLs at all. The rewrite
rule we used was incorrect. The trailing slash that we had added breaks the
component action URL parsing. It should read:
> RewriteCond %{HTTP_COOKIE} custom_ins=([-0-9][0-9]*)
> RewriteRule ^/friendlyUrl/(.*)/?$ /cgi-bin/WebObjects/<AppName>.woa/%1/$1
> [PT,L]
On 10 Sep 2010, at 15:44, Brook, James wrote:
> 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 (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/jbrook%40upcbroadband.com
>>
>> This email sent to jbr...@upcbroadband.com
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/jbrook%40upcbroadband.com
>
> This email sent to jbr...@upcbroadband.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
