On 08/02/2023 12:26, Reto Weiss wrote:
Hi There
I use Tomcat 9.0.68 and the
org.apache.catalina.filters.RemoteIpFilter**Filter behind a NGINX
reverse proxy. On the NGINX I set the http header X-Forwarded-Proto to
https.
If I now make a request with a Browser to the reverse proxy the
On 05/02/2018 03:18, Dave Glasser wrote:
> Thanks, that is pretty clear and unambiguous, as is "The name of
> the parameter must be jsessionid." When the spec is in conflict with itself,
> I'm happy to consider Tomcat the reference implementation.
Technically, the RI is glassfish.
This sort
Thanks, that is pretty clear and unambiguous, as is "The name of
the parameter must be jsessionid." When the spec is in conflict with itself,
I'm happy to consider Tomcat the reference implementation.
The reason a session cookie name had to be specified in the first place was
because we
On 03/02/18 21:55, Dave Glasser wrote:
> This text is based on a stackoverflow question I posted earlier today:
> https://stackoverflow.com/questions/48600576/jsessionid-as-path-parameter-not-working-in-tomcat/48602272
>
>
> I'm using Tomcat 7.0.84, and my web app uses the Servlet 3.0 deployment
Am Montag, den 11.04.2016, 10:22 + schrieb Arno Schäfer:
> Hi Felix,
>
> thank you very much for that hint.
>
> > When a session gets 'authenticated' its id will change to prevent
> > session fixation attacks. If you are interested in the events telling
> > you the change you have two
Hi Felix,
thank you very much for that hint.
> When a session gets 'authenticated' its id will change to prevent
> session fixation attacks. If you are interested in the events telling
> you the change you have two possibilities:
ok, that explain, what I see :-)
> 1. Use servlet api 3.1 and
Am 07.04.2016 um 17:40 schrieb Arno Schäfer:
Hi all,
I have the following Problem: we have a very old, some kind of complex webapp,
that run under tomcat 7.0.54 on Windows.
I have to maintain some functionality and came to a point, what I can't
understand. Some requests have to have an
Read up on the emptySessionPath connector setting in the Tomcat configuration
guide. This will explain it.
-Original Message-
From: chad.da...@emc.com [mailto:chad.da...@emc.com]
Sent: Monday, October 24, 2011 10:34 AM
To: users@tomcat.apache.org
Subject: jsessionid cookie across
Read up on the emptySessionPath connector setting in the Tomcat
configuration guide. This will explain it.
Which, for the record, is here:
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
-
To unsubscribe,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chad,
On 10/24/2011 1:33 PM, chad.da...@emc.com wrote:
As I understand it, sessions are unique to each webapp. However,
I see the same jsessionid cookie being used for requests to two
different webapps in the same container. Is this correct?
2011/10/7 Paul Wilson paulalexwil...@gmail.com:
Hi there,
Simple question. If a client posts:
POST /app/main%3bjsessionid=BF18D19ED62BB5F78E519018E618FB64 HTTP/1.1
whilst also specifying:
Cookie: $Version=0; JSESSIONID=BF18D19ED62BB5F78E519018E618FB64;
$Path=/app/
isn't Tomcat supposed
On 7 October 2011 12:10, Konstantin Kolinko knst.koli...@gmail.com wrote:
2011/10/7 Paul Wilson paulalexwil...@gmail.com:
Hi there,
Simple question. If a client posts:
POST /app/main%3bjsessionid=BF18D19ED62BB5F78E519018E618FB64 HTTP/1.1
whilst also specifying:
Cookie:
On 15/10/2010 15:15, Juliano Daloia de Carvalho wrote:
Hi Folks!
I want to put some information on the JSESSIONID that tomcat
generates.
I'm using aspect programming so I don´t need to change the tomcat code
itself.
What information?
The
thing is that I found many points
.
Rob
-Original Message-
From: Brian [mailto:bbprefix-m...@yahoo.com]
Sent: 11 October 2010 17:06
To: 'Tomcat Users List'
Subject: RE: JSESSIONID weakness Severity in Tomcat 6.0.29?
Hi Mark,
Well, it seems that www.securitymetrics.com got crazy! They already
told me
(according to what I
have read in some forums), but now it is.
Thanks for all your help!
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Sunday, October 10, 2010 03:09 PM
To: Tomcat Users List
Subject: Re: JSESSIONID weakness Severity in Tomcat 6.0.29?
On 10/10/2010
On 10/10/2010 20:32, Brian wrote:
I'm not using Jrun, but I guess the vulnerability applies also to Tomcat
6.0.29 so they treated me as if I was using Jrun with that vulnerability.
That guess has no basis in fact.
Does anybody know what should I do to solve this now?
There is nothing to fix
[mailto:ma...@apache.org]
Sent: Sunday, October 10, 2010 02:46 PM
To: Tomcat Users List
Subject: Re: JSESSIONID weakness Severity in Tomcat 6.0.29?
On 10/10/2010 20:32, Brian wrote:
I'm not using Jrun, but I guess the vulnerability applies also to
Tomcat
6.0.29 so they treated me as if I
On 10/10/2010 20:59, Brian wrote:
Hi Mark,
Do you understand exactly what vulnerability are they talking about?
No. It doesn't make much sense to me at the minute. I'd ask for more
specific information.
For
some reason, they have determined that I have it, even though I'm not using
Jrun
[mailto:ma...@apache.org]
Sent: Sunday, October 10, 2010 03:09 PM
To: Tomcat Users List
Subject: Re: JSESSIONID weakness Severity in Tomcat 6.0.29?
On 10/10/2010 20:59, Brian wrote:
Hi Mark,
Do you understand exactly what vulnerability are they talking about?
No. It doesn't make much
to do? Is there any web page on the internet that explains the issue?
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Sunday, October 10, 2010 03:09 PM
To: Tomcat Users List
Subject: Re: JSESSIONID weakness Severity in Tomcat 6.0.29?
On 10/10/2010 20:59
From: Brian [mailto:bbprefix-m...@yahoo.com]
Subject: RE: JSESSIONID weakness Severity in Tomcat 6.0.29?
I'm not using either basic or form. I developed my own
solution, which works great for me.
Apparently not, or you wouldn't have gotten the bad security review.
- Chuck
I must say you are right :-(
But I will solve it! :-)
-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: Sunday, October 10, 2010 06:44 PM
To: Tomcat Users List
Subject: RE: JSESSIONID weakness Severity in Tomcat 6.0.29?
From: Brian
Thanks!
It was as easy as Googling the subject, but I didn't know what was exactly
the name of it.
-Original Message-
From: Ken Bowen [mailto:kbo...@als.com]
Sent: Sunday, October 10, 2010 05:52 PM
To: Tomcat Users List
Subject: Re: JSESSIONID weakness Severity in Tomcat 6.0.29
From: Brian [mailto:bbprefix-m...@yahoo.com]
Subject: RE: JSESSIONID weakness Severity in Tomcat 6.0.29?
It was as easy as Googling the subject, but I didn't know
what was exactly the name of it.
More seriously: is there a particular reason you chose to roll your own
security mechanism
: JSESSIONID weakness Severity in Tomcat 6.0.29?
From: Brian [mailto:bbprefix-m...@yahoo.com]
Subject: RE: JSESSIONID weakness Severity in Tomcat 6.0.29?
It was as easy as Googling the subject, but I didn't know what was
exactly the name of it.
More seriously: is there a particular
From: Brian [mailto:bbprefix-m...@yahoo.com]
Subject: RE: JSESSIONID weakness Severity in Tomcat 6.0.29?
I was not familiar with the options available in the
container itself. I am still not familiar indeed.
Probably the best place to start researching would be sections 7 and 12
Hi,
I have a few quesations i want to ask about jessionid in tomcat.
1. In our web based application which runs on HTTPS, we have observed that
the jsessionid is being appended to the URL. On close examination, we have
observed that this is being added by tomcat to the url (Handled by the
Richard, there are two ways of maitaining sessions:
1) Using cookies (generally Tomcat's preferred way);
2) Using URL rewriting (generally Tomcat's less preferred way, used where a
client has turned off cookies).
There are no other ways of sending session IDs that are supported by all Web
From: Richard Nduka [mailto:richies4...@gmail.com]
Subject: jsessionid problem
I have a few quesations i want to ask about jessionid in tomcat.
Thanks for asking twice - two minutes apart. A tad impatient, are we?
Also too impatient to mention the Tomcat version, JVM you're using, platform
On 21 May 2010 16:16, Caldarale, Charles R chuck.caldar...@unisys.comwrote:
From: Richard Nduka [mailto:richies4...@gmail.com]
Subject: jsessionid problem
I have a few quesations i want to ask about jessionid in tomcat.
Thanks for asking twice - two minutes apart. A tad impatient, are
Hi Chuck/Peter,
Thanks guys for your mail.
First of all, we are not fronting tomcat with any other web server or
application server apart from the proxy server (Squid) that seats in front
of tomcat.
Secondly, we have not disabled cookies. In our context, we have cookies set
to true and cookie
From: Richard Nduka [mailto:richies4...@gmail.com]
Subject: Re: jsessionid problem
First of all, we are not fronting tomcat with any other web server or
application server apart from the proxy server (Squid) that seats in
front of tomcat.
Are you using clustering?
Secondly, we have
but if i change to
HTTPS (8443) then it is appended.
Thanks.
On Fri, May 21, 2010 at 4:59 PM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
From: Richard Nduka [mailto:richies4...@gmail.com]
Subject: Re: jsessionid problem
First of all, we are not fronting tomcat with any other
R wrote:
From: Richard Nduka [mailto:richies4...@gmail.com]
Subject: Re: jsessionid problem
First of all, we are not fronting tomcat with any other web server or
application server apart from the proxy server (Squid) that seats in
front of tomcat.
Are you using clustering
On 21/05/2010 17:09, Richard Nduka wrote:
It is a direct request. Typically, it happens for the first time when a user
enters the application url in a browser and the login page appears with the
jsessionid appended in the url.
That is expected. Tomcat doesn't know if the browser supports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard,
On 5/21/2010 11:45 AM, Richard Nduka wrote:
Secondly, we have not disabled cookies. In our context, we have cookies set
to true and cookie is enabled in the browser. For some reason, tomcat still
re-writes the URL and includes the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard,
On 5/21/2010 12:07 PM, Richard Nduka wrote:
Thanks again for your reply.
1. We are not using clustering.
2. I have checked in the locations mentioned and more and cannot see
anywhere that cookies is disabled.
3. However what
Hi Chris,
Thanks for your mail. Actually we were analysing our proxy server logs and
saw that a lot of URLs with jsessionid appended were being cached and this
even includes static files. We saw request for static files like images and
.js files being appended with jsessionid. So i think it
Hi Jim
There may be another mis-configured server out there that produces
JSESSIONID cookies with a domain-wide scope. SAP portals are a known
problem.
Best of luck
Regards
Ron
- Original Message -
From: Jim Goodspeed goodspeeds...@gmail.com
To: users@tomcat.apache.org
Sent:
2010/4/21 Jim Goodspeed goodspeeds...@gmail.com:
Our current setup is two hardware load balancers (layer 4) in front of two
Apache servers (2.2.14) which sit in front of two tomcat servers (6.0.20).
The hardware load balancers load balance apache and apache load balances
tomcat using AJP via
From: Marian Simpetru [mailto:marian.simpe...@esolutions.ro]
Subject: JSESSIONID and impact on google
When it came to google, we realized we are punished for using tomcat,
since there seems to be no way in disabling jsessionid (session id
appended to URL).
Of course there is - don't
On 09/02/2010 14:31, Marian Simpetru wrote:
Question is: Is there a way to configure tomcat to only use cookies (not
append jsessionid to URL for cookie0less browsers). I've been told Jetty
or resin is configurable in this aspect.
There will be in Tomcat 7 onwards. Prior to that, using
Thank you,
I guess session is created since a user could change preferred
language.. In a portal is basic stuff. Then you need session since page
one. We write JSR168 portlets on top of the Liferay portal ..
It's really an useful feature.
Thanks for your time, we look forward for tomcat 7 I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marian,
On 2/9/2010 9:31 AM, Marian Simpetru wrote:
Google act as a non cookie browser and hence he is served with non
unique URLs (because of session ID is appended to URL).
I heard at one point that Google's crawler *did* support cookies. I
On 09/02/2010 15:46, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marian,
On 2/9/2010 9:31 AM, Marian Simpetru wrote:
Google act as a non cookie browser and hence he is served with non
unique URLs (because of session ID is appended to URL).
I heard at one point
On 09/02/2010 16:32, Marian Simpetru wrote:
jsessionid in URLs returned around 79 million search results.
Yep. I know they're there.
google search on jsessionid SEO will give you lots of examples.
On a question asked to google, they reply by explaining the algorithm
(multiple URL with same
If you want to be seo friendly then change the application so that
session is not in the url.
Google sees each unique url as one page. With each visit to a jsession
site it will see the same content on multiple pages and the score will
go down for those seo terms.
Simple answer: Use cookies for
On 04/01/2010 20:52, Ken Bowen wrote:
I'm seeing what I think is odd behavior regarding jsessionid's.
[My setup(s): Tomcat 6.0.20 on a MacBook Pro using Java 1.6.0_17,
Tomcat 6.0.18 on CentOS 5 using Java 1.6.0_12 ]
I'm seeing the same behavior on both systems, and the same
behavior happens
I'm not sure about that. Here's what seems to me to be the sequence
of events:
Browser sends initial request http://myapp.com
Tomcat creates session and generates page for this request.
Tomcat doesn't know that Browser supports cookies, so it
should append jsessionid (but
On 04/01/2010 21:43, Ken Bowen wrote:
I'm not sure about that.
Run through your test again, but this time:
a) look at the html source of the responses and/or look at the URLs for
the links you are clicking on before you click on them.
Here's what seems to me to be the sequence of
events:
Thanks Mark. That cleared it up for me:
Re: a) look at the html source of the responses and/or look at the
URLs for
the links you are clicking on before you click on them.
That's the trick. The source for that (in a JSP) looks like:
a href= %=response.encodeURL ( anotherPage.jsp )%
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mitch,
On 8/12/2009 7:08 PM, Mitch Claborn wrote:
The answer is: yes, there are times when the response is already
committed, so the valve is not a foolproof solution.
If the Valve wraps the request with an object that intercepts the
addCookie
I played a bit with that approach, but couldn't figure out how to get my
valve early enough in the chain.
Mitch
Christopher Schultz wrote:
Mitch,
On 8/12/2009 7:08 PM, Mitch Claborn wrote:
The answer is: yes, there are times when the response is already
committed, so the valve is not a
I was able to change the expiration on the cookie with a one line change
to org.apache.catalina.connector.Request and it works like I need it to.
What is the official way to request an enhancement to allow this to be
configurable?
mitch
Mitch Claborn wrote:
The answer is: yes, there are times
Mitch Claborn wrote:
I was able to change the expiration on the cookie with a one line change
to org.apache.catalina.connector.Request and it works like I need it to.
What is the official way to request an enhancement to allow this to be
configurable?
The correct way is to open a bugzilla
On 14/08/2009 19:32, Mitch Claborn wrote:
I was able to change the expiration on the cookie with a one line change
to org.apache.catalina.connector.Request and it works like I need it to.
What is the official way to request an enhancement to allow this to be
configurable?
Doesn't
anyone know if there is a use-case for sessionId surviving end-of-session?
Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
My usage is: I store the key to the user's shopping cart in the
session. I'd like the user to be able to come back a few days from now
and still find the items they have placed in their shopping cart. (This
is mostly for anonymous users who don't sign in until checkout.)
Mitch
Martin Gainty
On Wed, Aug 12, 2009 at 11:35 AM, Mitch Clabornmi...@claborn.net wrote:
My usage is: I store the key to the user's shopping cart in the
session.
If I understand you correctly, then you would need to serialize the
session when it ended, to be able to resurrect it and retrieve that
key, or have
Your best bet is to assign your own cookie. Then on new session
creation, look for the cookie and repopulate the new session with
shopping cart data.
--David
Mitch Claborn wrote:
My usage is: I store the key to the user's shopping cart in the
session. I'd like the user to be able to come
I don't have any problem with the session contents (on the tomcat
server). I'm in a tomcat cluster and the sessions are replicated
between members of the cluster. As long as at least one member of the
cluster is running, then the sessions survive. I don't mind if the
sessions on the server
If I can't find a another way that's what I'll have to do. I would be
surprised that this need doesn't come up more frequently.
Mitch
David Smith wrote:
Your best bet is to assign your own cookie. Then on new session
creation, look for the cookie and repopulate the new session with
shopping
It comes up all the time. The solution is typically to use a separate
cookie and *not* tie the persistent data to the browser session, since
the browser session is transient.
--
Len
On Wed, Aug 12, 2009 at 14:54, Mitch Claborn mi...@claborn.net wrote:
If I can't find a another way that's what
I was able to get the cookie permanent with a simple valve, code below.
Question: the new cookie will be ignored if the response has already
been committed (isCommitted()). In my brief testing, the new cookie
is being set, so the response must not be committed. Is it possible
that there might
The answer is: yes, there are times when the response is already
committed, so the valve is not a foolproof solution.
mitch
Mitch Claborn wrote:
I was able to get the cookie permanent with a simple valve, code below.
Question: the new cookie will be ignored if the response has already
Haftung
fuer den Inhalt uebernehmen.
Date: Wed, 12 Aug 2009 18:08:43 -0500
From: mi...@claborn.net
To: users@tomcat.apache.org
Subject: Re: JSESSIONID cookie permanent?
The answer is: yes, there are times when the response is already
committed, so the valve is not a foolproof solution
The session data is stored on the server, so if the JSESSIONID lasted
longer
than the session on the server, it would simply map to an expired
session.
What would happen in this case is the server would have no session
mapping
to that ID and simply allocate a new session, with a new
jsessionid is the only way to indentity the user logined.
if you get it ,you are this user.
but? we can check others , for example IP!
- Original Message -
From: Pieter Temmerman ptemmerman@sadiel.es
To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, March 13, 2009 5:15
From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
However, as the jsessionid URL rewriting is defined in the servlet
specification, I would expect this to be secure.
Why, out of interest?
Therefor I was wondering whether the hijacking is caused by a
misconfiguration of Tomcat, my
However, as the jsessionid URL rewriting is defined in the servlet
specification, I would expect this to be secure.
Why, out of interest?
I don't know. It just seemed way to easy to hijack a session, so I
supposed it must be secure.
It's completely normal. Other frameworks have exactly
From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
I don't know. It just seemed way to easy to hijack a session, so I
supposed it must be secure.
Large portions of the web architecture are insecure by their original design.
This makes security in web-based systems... erm.. a challenge
2009/3/13 zhaoxueqing zhaoxueq...@g-data.com.cn:
jsessionid is the only way to indentity the user logined.
if you get it ,you are this user.
but? we can check others , for example IP!
But we can *still* do IP spoofing. Any other better recomendation?
This issue is one of my concern also.
--
Just a word about associating a given session to one IP address, it
works alright and sure is a security enhancement - not sure though if
there are built-in support for that in tomcat though it can be
implemented at application layer. The major drawback of doing so
depends of your user's ISP IPs
From: Zaki Akhmad [mailto:zakiakh...@gmail.com]
2009/3/13 zhaoxueqing zhaoxueq...@g-data.com.cn:
jsessionid is the only way to indentity the user logined.
if you get it ,you are this user.
but? we can check others , for example IP!
Difficult, depending on your environment. Some ISPs run
Pieter Temmerman wrote:
Hi list.
I've got an issue which I would like to share with you guys.
My webapp requires a user to login, which on his turn creates a session
for that user.
Now, when I browse my webapp the address bar shows the current URL with
a JSESSIONID. Let's say:
Vinuth Madinur wrote:
Hi,
I'm facing this weird situation. I've a URL which is like this:
From: André Warnier [mailto:[EMAIL PROTECTED]
Subject: Re: jsessionid sent in URL is being ignored.
If the jsessionid was really a parameter in this URL, it
would need to be after the ?
No, the semicolon delimiter is correct. Look at section 7.1.3 of the Servlet
spec and the URI RFC (3986
Vinuth Madinur wrote:
So, is there a way to manage jsessionid url rewrite to have something
like below?
As a path embed:
http://domain/context/servlet/AEGH12SEWF33RFFSF?queryparam1=v1
Or as a query parameter:
http://domain/context/servlet?jsessionid=AEGH12SEWF33RFFSFqueryparam1=v1
Is it
: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2008 10:08 PM
To: Tomcat Users List
Subject: Re: JSESSIONID doesn't contain the port
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zsolt,
Zsolt Koppany wrote:
| How can we make tomcat-5.5.25 to store also port
with context path (but without port). It could be discussed
whether or not this is lucky but this is the case.
Zsolt
-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2008 10:08 PM
To: Tomcat Users List
Subject: Re: JSESSIONID doesn't contain
Caldarale, Charles R wrote:
From: Pid [mailto:[EMAIL PROTECTED]
Subject: Re: JSESSIONID doesn't contain the port
The problem is that the TC1 sets a value of JSESSIONID that does not
exist in TC2.
Go back and reread the original post. There's only one instance of Tomcat, but there
are two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zsolt,
Zsolt Koppany wrote:
| Our customer has two tomcats because one instance is the production
version
| of our application and the second one is a test instance of the new
version
| of the same application. Because of that the context-pathes are
On Fri, Jun 20, 2008 at 4:16 PM, Christopher Schultz
[EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zsolt,
Zsolt Koppany wrote:
| Our customer has two tomcats because one instance is the production
version
| of our application and the second one is a test instance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Leon,
Leon Rosenberg wrote:
| http://host:8000/theApp vs http://host:8080/theApp or whatever ports
| he uses? :-)
Oh, right. Duh!
Yeah... I think he's kinda screwed.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment:
Zsolt Koppany wrote:
Hi,
we have two web applications running on the same host (with the same tomcat)
but on DIFFERENT ports.
Buf, if one tomcat application refers on URL of the second application the
browser (FF-2.0.0.14 IE-6) get a NEW a new JSESSIONID thus the browser
looses its session-id
No,
they (must) use the same IP address.
Zsolt
-Original Message-
From: Pid [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2008 2:45 PM
To: Tomcat Users List
Subject: Re: JSESSIONID doesn't contain the port
Zsolt Koppany wrote:
Hi,
we have two web applications running
From: Zsolt Koppany [mailto:[EMAIL PROTECTED]
Subject: JSESSIONID doesn't contain the port
we have two web applications running on the same host (with
the same tomcat) but on DIFFERENT ports.
For curiosity's sake, why are you doing that?
Buf, if one tomcat application refers on URL of the
Caldarale, Charles R wrote:
From: Zsolt Koppany [mailto:[EMAIL PROTECTED]
Subject: JSESSIONID doesn't contain the port
we have two web applications running on the same host (with
the same tomcat) but on DIFFERENT ports.
For curiosity's sake, why are you doing that?
Buf, if one tomcat
On Thu, Jun 19, 2008 at 4:51 PM, André Warnier [EMAIL PROTECTED] wrote:
Now, maybe the issue is whether the session of one application can or cannot
be valid for the other. If they just shared a session (and a cookie), then
there would be harmony again.
Or the OP just renames one of his
Leon Rosenberg wrote:
On Thu, Jun 19, 2008 at 4:51 PM, André Warnier [EMAIL PROTECTED] wrote:
Now, maybe the issue is whether the session of one application can or cannot
be valid for the other. If they just shared a session (and a cookie), then
there would be harmony again.
Or the OP
but the path of the cookie. IMHO the path of the cookie is the webapp
context - /webappname
Leon.
On Thu, Jun 19, 2008 at 5:12 PM, André Warnier [EMAIL PROTECTED] wrote:
Leon Rosenberg wrote:
On Thu, Jun 19, 2008 at 4:51 PM, André Warnier [EMAIL PROTECTED] wrote:
Now, maybe the issue is
André Warnier wrote:
Leon Rosenberg wrote:
On Thu, Jun 19, 2008 at 4:51 PM, André Warnier [EMAIL PROTECTED] wrote:
Now, maybe the issue is whether the session of one application can or
cannot
be valid for the other. If they just shared a session (and a
cookie), then
there would be
On Thu, Jun 19, 2008 at 5:42 PM, Pid [EMAIL PROTECTED] wrote:
André Warnier wrote:
Leon Rosenberg wrote:
On Thu, Jun 19, 2008 at 4:51 PM, André Warnier [EMAIL PROTECTED] wrote:
Now, maybe the issue is whether the session of one application can or
cannot
be valid for the other. If they
Pid wrote:
André Warnier wrote:
Leon Rosenberg wrote:
On Thu, Jun 19, 2008 at 4:51 PM, André Warnier [EMAIL PROTECTED] wrote:
Now, maybe the issue is whether the session of one application can
or cannot
be valid for the other. If they just shared a session (and a
cookie), then
there
Leon Rosenberg wrote:
On Thu, Jun 19, 2008 at 5:42 PM, Pid [EMAIL PROTECTED] wrote:
André Warnier wrote:
Leon Rosenberg wrote:
On Thu, Jun 19, 2008 at 4:51 PM, André Warnier [EMAIL PROTECTED] wrote:
Now, maybe the issue is whether the session of one application can or
cannot
be valid for
On Thu, Jun 19, 2008 at 6:09 PM, André Warnier [EMAIL PROTECTED] wrote:
So now that it is settled that different names for the cookies /would/ solve
the problem, is that a possibility in Tomcat ?
Is it possible for one application to influence the name of it's session
cookie, so that we
From: Pid [mailto:[EMAIL PROTECTED]
Subject: Re: JSESSIONID doesn't contain the port
The problem is that the TC1 sets a value of JSESSIONID that does not
exist in TC2.
Go back and reread the original post. There's only one instance of Tomcat, but
there are two Connector elements, each
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Subject: Re: JSESSIONID doesn't contain the port
of course it would since there will be two different cookies with
different pathes referring to both different sessions.
The webapps could choose to generate their own cookies with the common
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zsolt,
Zsolt Koppany wrote:
| How can we make tomcat-5.5.25 to store also port into JSESSIONID?
You can't really do that, unless you want to hack-up TC's source.
What you could do is deploy your applications under different context
names, instead
mfs wrote:
Given the above context, i was wondering if there is some way i can provide
my own unique sessionId to the servlet container whenever it creates a
unique http session against a user.
You would need to write your own manager. You should be able to extend
1 - 100 of 119 matches
Mail list logo
