I've been browsing through the Shiro 1.1 source code and I see this:
*public DefaultWebSessionManager() {*
* Cookie cookie = new
SimpleCookie(ShiroHttpSession.DEFAULT_SESSION_ID_NAME);*
* cookie.setHttpOnly(true); //more secure, protects against XSS
attacks*
* this.sessionIdCookie = cookie;*
* this.sessionIdCookieEnabled = true;*
* }*
It looks like the name of the session cookie is hard coded. Am I looking in
the wrong place?
/Bengt
2012/6/29 Bengt Rodehav <[email protected]>
> Hello again Jared,
>
> After reading this:
>
> http://stackoverflow.com/questions/1612177/are-http-cookies-port-specific
>
> it seems that cookies are reused between different ports on the same
> server (strange behaviour). I'v also verified this while debugging in
> Chrome. I therefore intend to encode the port in the name of the session
> cookie, e g JSESSIONID_8081.
>
> However I cant seem to be get your advice to work. I've tried:
>
> - securityManager.sessionManager.cookie.name
> - securityManager.sessionManager.cookieName
>
> But there is no such property. I also cannot see the property when looking
> in the code. Did I misenterpret you? Remember I'm using Shiro 1.1 (not 1.2).
>
> /Bengt
>
> 2012/6/20 Bengt Rodehav <[email protected]>
>
>> Thanks a lot for you reply Jared,
>>
>> I'm using native Shiro sessions. Will try setting the property you
>> suggest - thanks!
>>
>> I'll also check whether the cookies really interfer - I haven't
>> investigated it thoroughly yet. I just noted that if I log into another
>> application on the same host (but different ports) then the first
>> application is logged out. I then assumed that the session cookies
>> overwrote each other but I honestly don't know if that is the case.
>>
>> Whether the port is part of the "key" for the cookie could perhaps be
>> browser specific. I've only tested this on Chrome yet.
>>
>> /Bengt
>>
>>
>> 2012/6/20 Jared Bunting <[email protected]>
>>
>>> Are you using native shiro sessions or container-managed sessions? If
>>> native shiro sessions, you should be able to do something like this in
>>> shiro.ini:
>>>
>>> sessionManager.cookie.name=JSESSIONID_A
>>>
>>> Otherwise, you would need to consult your container to figure out how
>>> to change the cookie name.
>>>
>>> However, it seems odd to me that cookies for apps on different ports
>>> would interfere with each other.
>>>
>>> -Jared
>>>
>>> On Wed 20 Jun 2012 01:48:27 PM CDT, Bengt Rodehav wrote:
>>> > Does no one has any advice regarding this? I was hoping it was a not
>>> > so uncommon issue.
>>> >
>>> > /Bengt
>>> >
>>> > 2012/6/18 Bengt Rodehav <[email protected] <mailto:[email protected]>>
>>> >
>>> > I'm using Shiro 1.1 running in Apache Karaf 2.2.5.
>>> >
>>> > Often I install more than one web application on the same server
>>> > (but using different ports). These applications are unrelated.
>>> > However if I open them in separate tabs in the web browser they
>>> > start interfering with each other. Imagine this scenario:
>>> >
>>> > - Web application A and B are both installed on the same server.
>>> > - Open the URL to application A in the first tab in the web
>>> > browser and then log in
>>> > - Open the URL to application B in the second tab in the web
>>> > browser and then log in
>>> > - Go back to the first tab in the web browser and issue a request.
>>> > I then have to log in again since the server does not recognize
>>> > the session id.
>>> >
>>> > I haven't debugged this thoroughly but I think the problem is that
>>> > the same cookie name (JSESSIONID) is used by both web
>>> > applications. Therefore, the second log in (to application B) will
>>> > overwrite the session id from the first log in.
>>> >
>>> > I'm not sure if I'm doing something wrong here - this seems like a
>>> > very common scenario (especially in a test environment). The
>>> > obvious solution would be to make the name of the session cookie
>>> > configurable so that application A could use a cookie called
>>> > "JSESSIONID_A" and application B could use a cookie called
>>> > "JSESSIONID_B". Is this possible with Shiro? Is there
>>> > another/better way to solve this problem?
>>> >
>>> > /Bengt
>>> >
>>> >
>>>
>>>
>>>
>>
>
