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
JSESSI
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 initiall
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 possi
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 u
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 authent
-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?
> 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, e-
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 webapp
On 7 October 2011 12:10, Konstantin Kolinko wrote:
> 2011/10/7 Paul Wilson :
> > Hi there,
> >
> > Simple question. If a client posts:
> >
> > POST /app/main%3bjsessionid=BF18D19ED62BB5F78E519018E618FB64 HTTP/1.1
> >
> > whilst also specifying:
> >
> > Cookie: $Version="0"; JSESSIONID=BF18D19ED62
2011/10/7 Paul Wilson :
> 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 to strip t
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
.
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.securitymetric
(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
> 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 a
st
> 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
> > exa
> 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 y
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 Sever
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.
> 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
that the "session fixation" is my problem, what would you suggest
> me 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
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, Brian wrote:
> > Hi Mark,
> >
> > Do you
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
> J
-
> From: Mark Thomas [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 vulnerabilit
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 fi
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 happen
-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 wha
-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 jsess
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 coo
ote:
> >> 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
> >
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 a
On 21/05/2010 16:59, Caldarale, Charles 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
> 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?
>
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 is
On 21 May 2010 16:16, Caldarale, Charles R wrote:
> > 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
> 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, platf
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
browsers
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
encodeR
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"
To:
Sent: Wednesday, April 21, 2010 10:47 AM
Subject: JSES
2010/4/21 Jim Goodspeed :
> 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 mod_proxy. Apache an
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 s
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 c
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 th
-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
nev
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 gue
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 jses
> 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
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:
class="top_parent">Another Page
And when I hover
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:
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 d
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 happ
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 n
-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 me
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 HttpSession.
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 bugzil
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
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 JSESSION
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 val
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
>
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
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 wrote:
>
> If I can't find a another way that's what I'll have to do.
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
> shoppi
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 expir
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 b
On Wed, Aug 12, 2009 at 11:35 AM, Mitch Claborn 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 never-expiring s
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 w
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
sein,
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:
http://testweb/t
> From: Zaki Akhmad [mailto:zakiakh...@gmail.com]
> 2009/3/13 zhaoxueqing :
>
> > 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 large proxy clus
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 ma
2009/3/13 zhaoxueqing :
> 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.
--
Zaki Akhmad
-
> 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 challen
> > 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 ex
> 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
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"
To: "Tomcat Users List"
Sent: Friday, March 13, 2009 5:15 PM
Subject: JSESSIONID hijacking
> Hi list
> 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
Vinuth Madinur wrote:
Hi,
I'm facing this weird situation. I've a URL which is like this:
http://127.0.0.1:8080/hhc/call.htm;jsessionid=A9BA1447B82CB594B176D479288EAE1B?_flowId=careGiverTrack&_flowExecutionKey=_c46E07E3E-DC94-02A4-7961-763335C051A0_kC04C8A37-D22F-EF55-75E9-AD4514579721&_eventId
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=AEGH12SEWF33RFFSF&queryparam1=v1
Is it po
-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: U
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
-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
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 ther
ored in our wiki
> pages URL-s 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,
; From: 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:
&
-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 o
> 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 coo
> 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 t
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 tha
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
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
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
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 harmo
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, ma
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 ju
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
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 appli
> 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
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:
>
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 t
1 - 100 of 127 matches
Mail list logo
