Sorry the fix did not make it into 5.4.1 it will come later.
Pierre
--
Pierre Frisch
[EMAIL PROTECTED]
On Feb 25, 2008, at 2:47, Alexander Spohr wrote:
Q,
use wosid=false; to prevent the wosid.
bugreport:
5740184
WOHyperlink appends ?wosid to href
WebObjects
Other Bug
13-Feb-2008 05:08 AM
Duplicate/5657595
I think I filed this as a Serious Bug because it gives the wosid to
foreign and maybe unknown sites.
And there is a second bug!
If your URL has parameters, WO still appends a question-mark!
http://xyz?param=value
becomes:
http://xyz?param=value?wosid=xxxxxxxx
instead of
http://xyz?param=value&wosid=xxxxxxxx
atze
Am 25.02.2008 um 04:25 schrieb Q:
Digging up an old thread... forgive me.
I just noticed that the apple wo dev team have been bitten by this
very "feature" themselves, in JavaMonitor on 5.4.1. Links to
application instances now include the bogus wosid exactly as
described below.
Ouch! Match point Anjo.
On 20/12/2007, at 10:40 PM, Anjo Krank wrote:
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 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/qdolan%40gmail.com
This email sent to [EMAIL PROTECTED]
--
Seeya...Q
Quinton Dolan - [EMAIL PROTECTED]
Gold Coast, QLD, Australia (GMT+10)
Ph: +61 419 729 806
_______________________________________________
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/atze%40freeport.de
This email sent to [EMAIL PROTECTED]
Freeport & Soliversum
Alexander Spohr
[EMAIL PROTECTED]
www.freeport.de
_______________________________________________
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/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
