CloudBlue Technical Support

Symptoms

In some cases top frame in CCP and in PCP is not generated, like at the image below:

In UI log we can see that mainFrame and leftFrame are requested for the given bwid, but topFrame is not:

    ****************NEW REQUEST***************
    request scheme: https, data scheme: https
    data.getParameters():
    {bw_id=08608ba85081da0407dae96f6a5f366d}
    {referer=branding-477-cp.provider.tld}
    {never_used_param=x}
    {rendermode=leftFrame}
    .....
    ****************NEW REQUEST***************
    request scheme: https, data scheme: https
    data.getParameters():
    {referer=branding-477-cp.provider.tld}
    {rendermode=mainFrame}
    {bw_id=08608ba85081da0407dae96f6a5f366d}
    {never_used_param=x}

On the branding host in SSL access log file /usr/local/pem/vhosts/<WEBSPACE_ID>/log/ssl_access_log, where is the webspace ID for cp.provider.tld, we can see that 400 (Bad request) HTTP error is returned for the topFrame request:

    192.168.10.100 - - [21/Jan/2014:12:49:43 +0400] "GET /servlet/Turbine/renderMode/topFrame/bw_id/08608ba85081da0407dae96f6a5f366d HTTP/1.1" 400 - "https://cp.provider.tld/workspace.html?bw_id=08608ba85081da0407dae96f6a5f366d&cp=prv" "Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0" cp.provider.tld
    192.168.10.100 - - [21/Jan/2014:12:49:43 +0400] "GET /servlet/Turbine/renderMode/leftFrame/bw_id/08608ba85081da0407dae96f6a5f366d HTTP/1.1" 200 26419 "https://cp.provider.tld/workspace.html?bw_id=08608ba85081da0407dae96f6a5f366d&cp=prv" "Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0" cp.provider.tld
    192.168.10.100 - - [21/Jan/2014:12:49:43 +0400] "GET /servlet/Turbine/renderMode/mainFrame/bw_id/08608ba85081da0407dae96f6a5f366d HTTP/1.1" 200 17453 "https://cp.provider.tld/workspace.html?bw_id=08608ba85081da0407dae96f6a5f366d&cp=prv" "Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0" cp.provider.tld

Cause

Currently on every switch from OA to BA webgate creates a pair of cookies:

pem_navXXXXXXXXXXXXXXXXXX , pem_urlXXXXXXXXXXXXXXXXXX

Those are the session cookies and the standard lifetime for these cookies should be until a user closes the browser, but in certain browsers there are issues because of which such cookies are not destroyed when they should be. For example:

• In Chrome: Chrome doesn't delete session cookies

• In Firefox: Bug 794253 - Firefox doesn't delete cookies when quiting and Bug 401187 - auth cookies remain after restart firefox directly (reword "Keep [cookies] until: I close Firefox")

As a result, 400 Bad request can occur when the following scenario is used by a staff member constantly because there are too many cookies in the request:

1. Login in OA CP.
2. Switch to BA using the Billing link in the top frame and after that close tab.
3. Repeat this sequence n times.
4. Check cookies created for your OA CP domain: you will find n pairs of cookies like: pem_navXXXXXXXXXXXXXXXXXX , pem_urlXXXXXXXXXXXXXXXXXX, these cookies exist permanently in browser until you delete them manually.

Resolution

• Version 5.5: the issue has been fixed in OA 5.5 update 6 in scope of the bug APS-26226.

• Version 6.0: the issue has been fixed in OA 6.0 upate 6 in scope of the bug APS-28229.

For versions earlier than 5.5.6 and 6.0.6 the workaround is to clean the browser cookies. To fix the issue permanently, please contact Odin technical support.

Internal content