Hi Jan,
Thanks for the reply. You are completely right, overriding getExtendedId
DOES work. I must have made a mistake when I first tried that and
concluded the dot was not in super.getExtendedId. I was wrong, it is in
there.
Thanks a lot also for making the change.
Kind regards,
Silvio
On 01/07/2017 05:14 AM, Jan Bartel wrote:
Hi Silvio,
To get rid of the workername prefix, you should be able to set it to
"". To get rid of the .workername suffix, then it is sufficient to
override the
DefaultSessionIdManager.getExtendedId(String,HttpServletRequest)
method - if you're still seeing the suffix, that is wierd, because it
is only that method that creates it!
I'm going to make a change for 9.4.1 as follows:
* DefaultSessionIdManager.setWorkerName(null) will coerce null to ""
* if DefaultSessionIdManager.setWorkerName(String) is never called,
then the current code to set up a default worker name will be called
* ensure that the tests for prepending the workername and for
suffixing the .workername all skip the addition iff it is the empty
string or null
I'm attaching a diff that I'm working on if you want to apply it to
your local build before 9.4.1 comes out (which should be soonish).
Jan
On 6 January 2017 at 19:50, Silvio Bierman
<[email protected] <mailto:[email protected]>> wrote:
Hello Jan,
Thank you for the reply.
Perhaps worker name decoration has existed before 9.4 but then the
default worker name was probably null so we never say any worker
name related things in the session IDs. Now my worker name seems
to default to "node0" and setting it to null gives an NPE early
during server startup. Therefore I opted for "" but that leaves
the dot suffix. I guess reintroducing null handling would solve my
problems.
Firstly we have our own clustering logic that uses session ID
decoration and relies on some assumptions about what a default
session ID looks like. Both the increased length and the presence
of a dot breaks some of those assumptions.
Secondly our system runs user defined/manipulated scripts that
tend to do a lot of fiddling with URLs. Many scripts naively look
for a dot in the URL to find extensions like ".pdf" and replace
that with ".html" etc. Since we have the session ID in the URL
many of these scripts now fail because of the dot.
Finally we have one special case where we need to use a session ID
that is a checksum-padded UUID primary key (only used for
server-server communication behind the firewall). We used to do
this by overriding newSessionId.
I tried overriding getExtendedId but that does not help. The dot
is still appended afterwards.
Cheers,
Silvio
On 01/06/2017 12:42 AM, Jan Bartel wrote:
Hi Silvio,
I don't really understand what you're trying to do, but as far as
session ids go:
* jetty has always appended "."+workername to the session id for
the jsessionid cookie/url param. This tells a load balancer which
jetty instance to direct subsequent requests to.
* for a while now (can't remember in which jetty release, but it
was a while ago) we started also prepending the workername to the
session id to try and ensure the id was unique within the cluster.
We've had always had handling in place if the workername was
null. But I think in 9.4 we have opted to always default it to a
value, and there may be new parts of the code that expect it
won't therefore be null. I'll have a look at it for 9.4.1.
Meanwhile, you can also override the
DefaultSessionIdManager.getExtendedId(String, HttpServletRequest)
to just return the id without the .workername appended.
Jan
On 5 January 2017 at 02:12, Silvio Bierman
<[email protected]
<mailto:[email protected]>> wrote:
To clarify my previous post: Jetty seems to append a dot and
the worker name to the subsequent session IDs (created from
requests originatin in the server itself). It does not do
this when the requests come from the outside.
Since I set the workername to empty to get rid of the worker
name prefix this results in only a dot being appended.
To double-check I tested with a build that reverts to 9.3 and
it is definitely a 9.4 issue.
Cheers,
Silvio
On 01/04/2017 12:28 PM, Silvio Bierman wrote:
Hello all,
I have an issue with session IDs generated by Jetty in my
application that embeds Jetty 9.4.
Initially I had the problem that Jetty prepends a worker
name into the session ID. Someone here suggested I
override the session ID generation (which I already do in
clustered mode). But setting the worker name to an empty
string appeared to work fine so I went for that.
But: on subsequent sessions that are generated by
requests that come from the server itself Jetty appends a
single dot (.) to newly created session IDs. Many URL
handling user code (which I have limited influence on) is
not prepared for this so many user scripts no longer work.
I attempted to resolve this by overriding
DefaultSessionIdManager#newSessionId after all and
explicitly filtering out the dot. But to my surprise the
session ID returned from there does not contain a dot.
Instead it is appended at some later stage.
How can I get full control over session ID generation to
get rid of any session id decoration?
Thanks in advance,
Cheers,
Silvio
_______________________________________________
jetty-users mailing list
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
<https://dev.eclipse.org/mailman/listinfo/jetty-users>
_______________________________________________
jetty-users mailing list
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
<https://dev.eclipse.org/mailman/listinfo/jetty-users>
--
Jan Bartel <[email protected] <mailto:[email protected]>>
www.webtide.com <http://www.webtide.com>
/Expert assistance from the creators of Jetty and CometD/
_______________________________________________
jetty-users mailing list
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
<https://dev.eclipse.org/mailman/listinfo/jetty-users>
_______________________________________________ jetty-users
mailing list [email protected]
<mailto:[email protected]> To change your delivery options,
retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
<https://dev.eclipse.org/mailman/listinfo/jetty-users>
--
Jan Bartel <[email protected] <mailto:[email protected]>>
www.webtide.com <http://www.webtide.com> /Expert assistance from the
creators of Jetty and CometD/
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
