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 de
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
D
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
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, a
Wow, I sure touched off some fiery debate here – sorry guys. If I can
summarize the two main points:
1) WO 5.4 acts differently to 5.3 by adding a ?wosid=... part on the
end of a URL.
That is bad and will cause all sorts of compatibility problems and
existing systems to break.
2) It see
On 20.12.2007, at 12:21, Andrew Lindesay wrote:
This is a departure from WO 5.3.3, but it seems to be OK to me;
?
In WO 5.3 you don't need that if your using the href binding. You only
need it on WO 5.4. And that is not okay with me, as I'd have to go
through all apps I've ever created as
Hello;
...or There is a binding ?wosid=false
This is a departure from WO 5.3.3, but it seems to be OK to me; just
need add this binding to the hyperlinks that are external. Maybe if
this is applied universally then it makes things more consistent in
WO 5.4?
cheers.
___
Andrew Lind
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=) is in the
query parameters as Mike suggested. This would ensure backwards
compatibility and allow devs to conciously use the new feature of
adding
I am trying to find a solution along those lines. It is not very easy
because all those API used to hidden in WO 5.3 and are now public in
WO 5.4 to give you more control on the query dictionary so I have
quite a few constraints.
Pierre
--
Pierre Frisch
[EMAIL PROTECTED]
On Dec 20, 2007,
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
It seems li
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:
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 ide
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
Maybe I'm missing something here. But calling setStoresIDsInURLs(false) from
one's session constructor takes care of this issue:
public Session() {
super();
setStoresIDsInURLs(false);
}
We were caught by surprise with this new "feature". But the above one-liner
took care of it. We
Oops! :-P
That seems a pretty clear cut reason to NOT have this added to the
URL.
AND potentially messing up other WO apps what you might refer to, like
http://.../AppA.woa/wa/cool?wosid=sessionfromAppB
When AppA might have a cookie set or the URL already constructed
correctly?
Botto
In particular as this is a glaring security issue as you'd be
exposing WOSIDs to other sites which have no business with it!
Aside from being 100% right (as always) anyway ;) , this is a very
valid point.
ms
___
Do not post admin requests to the li
On Dec 19, 2007, at 3:18 PM, Anjo Krank wrote:
In particular as this is a glaring security issue as you'd be
exposing WOSIDs to other sites which have no business with it!
"Oh my, why don't I check the logs for this stupid apple app server
and see if I can plunder their accounts!"
Sweet,
In particular as this is a glaring security issue as you'd be exposing
WOSIDs to other sites which have no business with it!
"Oh my, why don't I check the logs for this stupid apple app server
and see if I can plunder their accounts!"
Sweet, Anjo
Am 20.12.2007 um 00:15 schrieb Anjo Krank:
Am 19.12.2007 um 22:41 schrieb Chuck Hill:
FWIW, I agree with Guido on this one.
Me too, 100%.
In particular as this used to work differently. If you WANT to return
a WOSID, you'd normally do it by returning context.directActionURL()
or whatever, which includes is if you want it. To seco
FWIW, I agree with Guido on this one.
Chuck
On Dec 19, 2007, at 10:09 AM, Guido Neitzer wrote:
On 19.12.2007, at 06:36, Jean-François Veillette wrote:
If you know the href, and don't want any WO mungling, just use
directly, or use WOGenericContainer if the href is hand made.
WOHyperlink i
On 19.12.2007, at 06:36, Jean-François Veillette wrote:
If you know the href, and don't want any WO mungling, just use
directly, or use WOGenericContainer if the href is hand made.
WOHyperlink is for WO, so it deal with wo session if one exist.
I know my ways around that, that's not the pro
Thanks Pierre, that works a treat and is much more elegant – as you
say let WO do the work. I'll leave Guido and you to work out whether
it's a bug in 5.3 or 5.4.
Ian
On 19/12/2007, at 11:09 AM, Mr. Pierre Frisch wrote:
Actually what I would consider an even better style would be:
On 18.12.2007, at 19:44, Mr. Pierre Frisch wrote:
So in the case you mention if the hyperlink is generated in response
to direct action with no session the session ID will not be added to
the URL. If there is a session as it is typical in a component
response page you will get a session ID,
Guido,
The exact behavior is that no session ID is added 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
On 18.12.2007, at 17:04, Mr. Pierre Frisch wrote:
As far as I can see this is a correct behavior even if it is not
what you expected.
Are you sure about that?
If I have (in a clean new application) a hyperlink defined with:
Link : WOHyperlink {
href = href;
}
And the method does th
18, 2007 4:10 PM
To: WebObjects (Group)
Subject: Re: Wosid suppression broken in 5.4?
Actually what I would consider an even better style would be:
public String downloadPath() {
return "/Somepath/test.pdf";
}
Hyperlink7: WOHyperlink {
directActionName = "download_vi
Actually what I would consider an even better style would be:
public String downloadPath() {
return "/Somepath/test.pdf";
}
Hyperlink7: WOHyperlink {
directActionName = "download_video";
?filePath = downloadPath;
?wosid=false;
}
Make WebOb
As far as I can see this is a correct behavior even if it is not what
you expected.
when you execute directActionURLForActionNamed on the context you
create a fragment URL that includes a query string. If you pass this
to WOHyperlink it will take the string as a URL fragment check if
ther
On 18-Dec-07, at 4:42 PM, Mr. Pierre Frisch wrote:
I am looking as to the why. On the short term just add this to your
bindings
?wosid=false;
great :D That solved my problem!
Thank you very much for all your help. Cheers,
Edgar
On Dec 18, 2007, at 10:59, Edgar Klein wrote
I am looking as to the why. On the short term just add this to your
bindings
?wosid=false;
Pierre
--
Pierre Frisch
[EMAIL PROTECTED]
On Dec 18, 2007, at 10:59, Edgar Klein wrote:
Hi,
On 16-Dec-07, at 10:47 PM, Ian Joyner wrote:
I have this little bit of code to invoke a
Hi,
On 16-Dec-07, at 10:47 PM, Ian Joyner wrote:
I have this little bit of code to invoke a direct action to download
a file:
public String download_link () {
return context ().directActionURLForActionNamed
("download_video",
We have been seeing those as well on our hyperlinks all of the sudden after
we upgraded to 5.4
On 12/17/07 6:20 PM, "Ian Joyner" <[EMAIL PROTECTED]> wrote:
> Sorry, no joy in the release notes.
>
> So does anyone know why the extra ?wosid is put on the end and if I am
> not doing something el
Sorry, no joy in the release notes.
So does anyone know why the extra ?wosid is put on the end and if I am
not doing something else to get rid of it?
Should I submit a bug report?
I think my workaround is checking for ?wosid at the end of the
filePath in the direct action method.
Thanks
Hi Ian,
From: Ian Joyner <[EMAIL PROTECTED]>
Actually, I think this is not the problem – printing out the result
from this function shows no ?wosid on the end:
Video_library (Video_library.java:download_link:1184) - result is /cgi-
bin/WebObjects/Stream.woa/wa/download_video?filePath=%2FLib
Actually, I think this is not the problem – printing out the result
from this function shows no ?wosid on the end:
Video_library (Video_library.java:download_link:1184) - result is /cgi-
bin/WebObjects/Stream.woa/wa/download_video?filePath=%2FLibrary
%2FStream%2FMovies%2FStreamatWRU.pdf
so
35 matches
Mail list logo
