Hi Shing Wai,
Thanks for the info on this. Good to have it confirmed that it's just
the cookie, so the only user who actually loses his session is the one
accessing the admin console, and only on that browser. (I should have
thought to test that myself with multiple browsers.)
Do you think it'd ever get any traction to file an RFE that the admin
console use a named cookie so it's not a surprise to developers? You
probably have enough to work on already. :)
Cheers,
Bobby
On Thu, Apr 19, 2012 at 8:41 PM, Shing Wai Chan
<shing.wai.chan_at_oracle.com> wrote:
> Hi Bobby,
> I have a second thought on the issue.
> Actually, you can workaround this by changing the "name" of the cookie
> by adding <name> element under <cookie-config> in the web.xml as follows:
>
> <session-config>
> <cookie-config>
> <name>MYJSESSIONID</name>
> </cookie-config>
> </session-config>
>
> I have verified that it works.
>
> Shing Wai Chan
>
>
> On 4/19/12 1:27 PM, Shing Wai Chan wrote:
>>
>> Hi Bobby,
>> You are correct.
>> In this case, the cookies have the same domain and path.
>> The port info (as mentioned in rfc 2965) is not there as it may not be
>> followed by browsers.
>> Hence, the cookies will overwrite each other.
>> One may like to use a different browser for admingui and context root /
>> app in this case.
>>
>> Shing Wai Chan
>>
>> On 4/15/12 12:28 PM, Bobby Bissett wrote:
>>>
>>> Hi all,
>>>
>>> This is something I've seen intermittently, but never bothered to
>>> track down until now. It's very simple to recreate using a new 3.1.2
>>> GF installation. If I deploy an application at / and use it, then if I
>>> load the admin console as well the session gets lost for my
>>> application. If I start over there, then the admin console session is
>>> lost. Am guessing it's just a side effect of two applications setting
>>> cookies at /, but it's not a good user experience to have everyone
>>> effective logged out if I need to use the admin console (not to
>>> mention that the admin console is unusable with users constantly
>>> logging in). Is this a bug in GF or something unavoidable if I'm
>>> deploying apps to the DAS? FWIW, I don't remember this in GF 2.X.
>>>
>>> To recreate, use the attached app (zip has one class and pom.xml).
>>> Start GF, deploy app to / and go to http://localhost:8080 in a
>>> browser. Click the button a couple times to increment the counter.
>>> Then load the admin console in another tab and go back to app. When
>>> you click the button, you'll see an error message and have to reload
>>> the page, which starts a new session and starts the counter over at 0
>>> again. Then if you go back to the admin console you will have lost
>>> that session too.
>>>
>>> I know I could work around this by running the app on a standalone
>>> instance instead of the DAS, or by deploying to something other than
>>> /; am just curious if there's another option instead. Should I just
>>> change the context root for the __admingui app (or would that cause
>>> even more trouble for me).
>>>
>>> Thanks,
>>> Bobby
>>
>>
>