Re: Wosid suppression broken in 5.4?
Re: Wosid suppression broken in 5.4?
- Subject: Re: Wosid suppression broken in 5.4?
- From: Alexander Spohr <email@hidden>
- Date: Mon, 25 Feb 2008 18:21:47 +0100
Sorry to bother but I really would like to have a binding like
appendWosid = true/false
instead of explicitly setting the _parameter_ to false (which is
illogical in itself, as it should result in &wosid=false or &wosid=0
and not in the removal of the wosid).
And I'd really want a default behavior that does NOT append the wosid
when i construct the href myself. If I build the string WOHyperlink
should keep its hands off!
If I really would like to have it I could use
?wosid = session.sessionID;
and would be done (yea I know, this generates a session if i had none).
Or as I am already building the href myself I just paste it at the end
of the string - myself.
Really, I think this whole behaviour is a bug, not a feature.
atze
Am 25.02.2008 um 18:02 schrieb Mr. Pierre Frisch:
Sorry the fix did not make it into 5.4.1 it will come later.
Pierre
--
Pierre Frisch
email@hidden
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@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
--
Seeya...Q
Quinton Dolan - email@hidden
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Freeport & Soliversum
Alexander Spohr
email@hidden
www.freeport.de
_______________________________________________
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
Freeport & Soliversum
Alexander Spohr
email@hidden
www.freeport.de
_______________________________________________
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