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.

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

Email subscription for changes to this article
Save as PDF