Article ID: 128817, created on May 10, 2016, last review on Jun 12, 2016

  • Applies to:
  • Operations Automation 6.0
  • Operations Automation 5.5

Symptoms

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

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:

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.

Search Words

APS-28229

Top Frame is not shown sometimes in POA CP

POA-82424

Provider reseller CP top frame is blank white

topframe

top frame

5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 e12cea1d47a3125d335d68e6d4e15e07 956c448bddc7e1f3585373687602379f 6f1456866eed87488c0f02b298a741c0 5b048d9bddf8048a00aba7e0bdadef37 2554725ed606193dd9bbce21365bed4e

Email subscription for changes to this article
Save as PDF