So, why not add this
or href is bound
... and the only time a wosid is added automatically is if href is
bound AND if (wosid=<anything except FALSE || false || 0>) is in the
query parameters as Mike suggested. This would ensure backwards
compatibility and allow devs to conciously use the new feature of
adding a wosid in the rare cases that they use a href to talk to the
same app instance?
Regards, Kieran
On Dec 20, 2007, at 6:59 AM, Mr. Pierre Frisch wrote:
Anjo,
Before you go in this kind of pronouncements I have a few points to
make.
The reason this works the way it works is because we would like to
support query dictionaries on URLs. The current behavior is the
default for WOHyperlink i.e. we handle the query dictionary and
fragment identifiers. We therefore append the URL with the correct
information. Part of the query dictionary is the session ID. The
session ID is NOT included if either of this is true:
No session exist before the call (typically a direct action)
or The session id is not stored in the URL (i.e. it is stored in
the cookie)
or There is a binding ?wosid=false
or The query dictionary contains a key wosid bound to Boolean.FALSE
This is the correct behavior for links inside the current web site.
I agree that this not correct for links out of the current web
site, this however causes a problem as there is no way for
WebObjects to determine what is inside and what is outside of the
current Web site, only the Web server can.
Changing the behavior is quite straight forward as the query
dictionary is computed in the context:
public NSDictionary<String, Object> computeQueryDictionary(String
aRequestHandlerPath, NSDictionary<String, Object> queryDictionary,
NSDictionary<String, Object> otherQueryDictionary)
There is no need for a "Wonder patch", each developer can do what
they need.
Pierre
--
Pierre Frisch
[EMAIL PROTECTED]
On Dec 19, 2007, at 16:35, Anjo Krank wrote:
Am 20.12.2007 um 01:22 schrieb James C. Lee:
We were caught by surprise with this new "feature". But the above
one-liner
took care of it. We actually did this in our BaseSession class,
which all
apps subclass from. While we're on the subject of session IDs,
also do this
in the constructor:
Wow. I see. You ARE sure that this one liner actually takes care of:
- having older apps still work for which you neither have source
nor time to work on
- having both the cookie and the ULR work if they are not on sync
- have distributed responsibilities, where some people might allow
cookies and some not
This is just OTOMH, I'm sure I can come up with extra cool XSS
stuff when I put my mind into it. But I no wanna.
Do YOU really want to wade around >3k components just for the heck
of it to make sure that wosid=false is set in each case? And for
*what* again?
Again: It is broken. Please fix, thanks. I don't want to hear
about workarounds, it affects stuff you don't and can't even know
or care about for no reason at all. If Pierre doesn't fix it,
Wonder will.
Cheers, Anjo
_______________________________________________
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/pierre%
40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/kieran_lists%
40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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 [EMAIL PROTECTED]
