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