Re: Wosid suppression broken in 5.4?
Re: Wosid suppression broken in 5.4?
- Subject: Re: Wosid suppression broken in 5.4?
- From: Anjo Krank <email@hidden>
- Date: Thu, 20 Dec 2007 13:40:22 +0100
Pierre,
I think it's a bug, but MY main concern is that there are no hard-to-
track changes in WO that might lead to undesirable results that you
only stumble upon by accident - which clearly is the case if
WOHyperlink behaved differently in the past.
Now, I just checked that in 5.3 this:
<webobject name = "HyperlinkWithSession"> HyperlinkWithSession </
webobject>
<webobject name = "HyperlinkWithoutSession"> HyperlinkWithoutSession </
webobject>
Hyperlink1 : WOHyperlink {
action = application.name;
}
Hyperlink : WOHyperlink {
href = "/";
}
produces this:
<a href="/cgi-bin/WebObjects/FrontAK.woa/1/wo/aanRcdAiZIn5aVH28ifbhw/
298.0.0.0.0.0.13.3.11.0.2">HyperlinkWithSession</a>
<a href="/">HyperlinkWithoutSession</a>
Which looks right to me. Now, IF 5.4 instead produces:
<a href="/cgi-bin/WebObjects/FrontAK.woa/1/wo/aanRcdAiZIn5aVH28ifbhw/
298.0.0.0.0.0.13.3.11.0.2">HyperlinkWithSession</a>
<a href="/?wosid=aanRcdAiZIn5aVH28ifbhw">HyperlinkWithoutSession</a>
then that would be unacceptable in many ways: it's plain wrong, it
introduces security issues that were not present before, it makes
deploying multiple apps in one site a guessing game which the correct
WOSID will be if you have a mix of cookie/non-cookie sessions and
you'll get hundreds of developers to check many thousands for existing
components for this if they care a little bit about such things.
So yes, we WILL fix this in Wonder and yes it IS needed at the
WOHyperlink level and not programmatically by mucking with the context
and we of course only do this because WE know what is good for you :)
And I totally like pronouncements, so there (whatever they are).
If, on the other hand, I got sth wrong here and the output is the
same, never mind. Go along then, there is nothing to see.
Cheers, Anjo
Am 20.12.2007 um 12:59 schrieb Mr. Pierre Frisch:
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@hidden
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
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