API Management OAuth Toolkit (OTK): OAuth Manager login page shows HTML & CSS page source code instead of the expected page view


Article ID: 8354


Updated On:


CA Mobile API Gateway CA API Gateway


This article will discuss a situation where the OAuth Manager login page (found at the /oauth/manager service path) may show source code instead of the expected page content. The source code seen may look similar to the example below:

<!DOCTYPE html>



    <title>OAuth Manager</title>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

    <meta http-equiv="X-UA-Compatible" content="IE=8,IE=9,IE=10,IE=11,chrome=1" />

    <style type="text/css">

/* normalize v2.0.1 */

/*article,aside,details,figcaption,figure,footer,header,hgroup,nav,section,summary{display:block}audio,canvas,video{display:inline-block}audio:not([controls]){display:none;height:0}[hidden]{display:none}html{font-family:sans-serif;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%}body{margin:0}a:focus{outline:thin dotted}a:active,a:hover{outline:0}h1{font-size:2em}abbr[title]{border-bottom:1px dotted}b,strong{font-weight:700}dfn{font-style:italic}mark{background:#ff0;color:#000}code,kbd,pre,samp{font-family:monospace,serif;font-size:1em}pre{white-space:pre;white-space:pre-wrap;word-wrap:break-word}q{quotes:"\201C" "\201D" "\2018" "\2019"}small{font-size:80%}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}sup{top:-.5em}sub{bottom:-.25em}img{border:0}svg:not(:root){overflow:hidden}figure{margin:0}fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em}legend{border:0;padding:0}button,input,select,textarea{font-family:inherit;font-size:100%;margin:0}button,input{line-height:normal}button,html input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer}button[disabled],input[disabled]{cursor:default}input[type=checkbox],input[type=radio]{box-sizing:border-box;padding:0}input[type=search]{-webkit-appearance:textfield;-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box}input[type=search]::-webkit-search-cancel-button,input[type=search]::-webkit-search-decoration{-webkit-appearance:none}button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0}textarea{overflow:auto;vertical-align:top}table{border-collapse:collapse;border-spacing:0}

*/html{font-family:sans-serif;-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%;}body{margin:0;}article,aside,details,figcaption,figure,footer,header,hgroup,main,nav,section,summary{display:block;}audio,canvas,progress,video{display:inline-block;vertical-align:baseline;}audio:not([controls]){display:none;height:0;}[hidden],template{display:none;}a{background:transparent;}a:active,a:hover{outline:0;}abbr[title]{border-bottom:1px dotted;}dfn{font-style:italic;}h1{font-size:2em;margin:.67em 0;}mark{background:#ff0;color:#000;}small{font-size:80%;}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline;}sup{top:-.5em;}sub{bottom:-.25em;}img{border:0;}svg:not(:root){overflow:hidden;}figure{margin:1em 40px;}hr{-moz-box-sizing:content-box;box-sizing:content-box;height:0;}code,kbd,pre,samp{font-family:monospace, monospace;font-size:1em;}button,input,optgroup,select,textarea{color:inherit;font:inherit;margin:0;}button{overflow:visible;}button,select{text-transform:none;}button,html input[type=button],/* 1 */ input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer;}button[disabled],html input[disabled]{cursor:default;}input{line-height:normal;}input[type=checkbox],input[type=radio]{box-sizing:border-box;padding:0;}input[type=number]::-webkit-inner-spin-button,input[type=number]::-webkit-outer-spin-button{height:auto;}input[type=search]{-webkit-appearance:textfield;-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box;}input[type=search]::-webkit-search-cancel-button,input[type=search]::-webkit-search-decoration{-webkit-appearance:none;}fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em;}table{border-collapse:collapse;border-spacing:0;}td,th{padding:0;}b,strong,optgroup{font-weight:700;}pre,textarea{overflow:auto;}button::-moz-focus-inner,input::-moz-focus-inner,legend{border:0;padding:0;}


There is no single cause for these symptoms. It has been found that the overall root cause is usually one of three major situations:

  1. An ssgrestore was run on the Gateway to restore from a backup taken previously.
    • In the restore process, permissions may not have been put back the way they should have been by the ssgrestore script.
  2. "Something" manipulating the data before it arrives to the client requesting the OAuth Manager page. This includes the following example scenarios found to be a root cause:
    • Threat protection assertions may interfere with the service by manipulating the data, depending on where they are located in policy. This is the most common root cause. They are often found in message-received Global Policy Fragments, which unintentionally manipulates the data streamed from the API Gateway back to the client. Threat protection assertions are discouraged from being added to any of the default out-of-the-box policies when using the OAuth Toolkit (OTK) or the Mobile API Gateway (MAG).
    • A message-completed Global Policy Fragment may not be valid or may contain assertions which are manipulating the data.
    • A message-received Global Policy Fragment may not be valid or may contain assertions which are manipulating the data.
  3. The database. Usually one of the following in this situation:
    • A database connection issue. This includes typos in the primary host when the connection string states a failover host as well.
    • An incomplete schema in the OTK database.


This article applies to all supported OTK and API Gateway versions. The issue affects the OAuth Manager pages when viewed with any web browser. The OAuth Manager ships with the OAuth Toolkit (OTK) and Mobile API Gateway (MAG) products.


If one of the causes noted in the causes section is found to exist in the environment, it should be corrected and loading of the OAuth Manager page tested again.

  1. If an ssgrestore was performed recently before the issue started happening, then the permissions for the assertions may need to be corrected manually. Ensure the permissions are set to 444 for the /opt/SecureSpan/Gateway/runtime/modules/lib/ directory by running the following command:
    • chmod -R 444 /opt/SecureSpan/Gateway/runtime/modules/lib/
  2. If there are additional threat protection assertions found in a message-received Global Policy Fragment, they may need to be temporarily removed in order to further troubleshoot or narrow down the root cause. This scenario requires various troubleshooting areas, unfortunately, and may be quite time consuming in finding the exact root cause in any particular environment.
  3. If there are no threat protection assertions or incomplete Global Policy Fragments, then the next likely root cause is a database connection issue or an improperly configured OTK database. In this scenario, follow the steps below:
    1. In Policy Manager, bring up the Manage JDBC Connections window found at Tasks > Manage Data SourcesManage JDBC Connections.
    2. Open up the JDBC Connection Properties window for the JDBC connection used for OTK, then click the Test button to test the connection. Confirm the Connection Name matches that used in the OTK policies.
      • If the above test fails, then there is a connection issue or credential issue. Review the hostname / IP value and ensure the username and password are correct.
      • If the above test passes, review the JDBC connection URL first. Even if the JDBC connection test passes, a root cause has still been identified previously that was due to a typo in the primary host when a secondary host for failover purposes was also specified. In such a setup, the test passed because the secondary hostname was correct, but the primary hostname was incorrect. When using the secondary host for connection, the JDBC connection will be in a read-only mode which will cause the issues described in this article. It can also be implied it's a typo or similar issue in the connection URL if the following log entry is seen in the SSG log on the Gateway:
        • WARNING 156 com.l7tech.server.jdbc.JdbcQueryingManagerImpl: Failed to perform querying since Connection is read-only. Queries leading to data modification are not allowed
    3. If the above are not root causes, then the next most likely root cause is a database schema issue for the OTK database. This can require a bit of manual effort to resolve. The following query can be used to retrieve the schema for the OTK database. Compare the output from the following query against the schema provided with the OTK installation files (linked in the Additional Information section). Database query to run: 
      • SELECT * FROM information_schema.columns WHERE table_schema = 'otk_db'\G;

Additional Information