It maybe different, but similar in nature. We currently do not support
running admin console for different domain on the same browser. Making
changes in the web config file will solve the combination of 'admin
console' and user app, but still cannot support running the console for
different domains in same browser case.
Anissa.
On 4/24/12 7:56 AM, Jason Lee wrote:
> From the looks of it in this thread, that sounds like a simple config
> change we can make in the console module itself, no?
>
> If nothing else, it can't hurt to file the RFE against the Console.
> We can figure out the specifics of the who and where later. :)
>
> On 04/24/2012 09:24 AM, Bobby Bissett wrote:
>> 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
>>>>
>
>