ApigeeX rendering hmac secret via developer portal

Along with the apikey , we are using additional security scheme of hmac secret. Is there an option of providing or showing the hmac secret values in portal for the respective developers registered for the product/app. hmac secrets in our case are specific to app

0 3 155
3 REPLIES 3

Are you not using the consumer secret as the HMAC secret?  I think the devportal by default will show the consumer secret.  And that's a good candidate to use for the key for the HMAC.  

 

we were not using consumer secret as a HMAC secret but that seems to be a very good idea. probably in our next refresh of hmac secret we would move to consumer secret for hmac secrets. There is an option of custom attributes in the app but when we add those we are not seeing them in the integrated developer portal. Is there a way to publish the custom attributes for a app in the portal?

Yes, whether you are using the Drupal developer portal or the Integrated developer portal, there is a way to do what you describe: display the custom attribute in the list of apps. You will need to write some customization code in either case. I'm sorry to say, It's not a case of "check the box and the custom attributes appear."


In the Drupal developer portal, you need to update the app template. It's the same template you'd need to update if you wanted to... for example.... display a notice under a key that was about to expire "soon". I think the name of the template is devconnect_developer_apps_list.tpl.php , which is in the directory profiles/apigee/themes/apigee_responsive/templates/devconnect . There are multiple tutorials I think, showing how to do this, so I won't cover it here further.


In the Integrated Developer portal, there is no PHP, but you can add your own custom script to the portal. To do that, use the Apigee UI to select

  • publish
  • Portals
  • (select your portal)
  • Settings
  • add custom script
  • and paste in your script. Be sure to include opening and closing <script> tags.

In the script, you will set a page event listener for onLoad. Within that, call a function that modifies the DOM.

Something like this:

 

window.portal = {};
window.portal.pageEventListeners = {
  onLoad: (path) => {
    /* do not match on /my-apps/new */
    let re1 = new RegExp('/my-apps/(((.+)-){4}(.+))$'),
        match = path.match(re1);
    if (match && match[1]) {
      let div = document.querySelector('div.app-section-api-keys');
      setTimeout(() => modifyDom(div), 200);
      return true;
    }
    return undefined;
  },
  onUnload: (path, contextReturnedFromOnLoad) => {
  }
};

 

Within your modifyDom() function, you want to do something like this:

 

      let method = 'GET';
      let credentials = 'same-origin';
      let url = `/consumers/api/apps`;
      let headers = {
            'Accept': 'application/json'
          };
      let body = null;
      headers['X-Apigee-CSRF'] = getCsrfHeader();

      return fetch(url, { method, credentials, headers, body })
        .then( (appsResponse) => function(appsResponse) {
              // parse appsResponse, inject custom attrs in appropriate table cells
        });

 

And the only other thing is figuring out the Csrf Header. I do that with something like this:

 

function getCsrfHeader() {
  let x = document.cookie
    .split(';')
    .map(e => e.trim())
    .find(item => item.startsWith('X-Apigee-CSRF'));
  if (x) {
    let parts = x.split('=');
    if (parts && parts.length > 1) {
      return parts.slice(1).join('=');
    }
  }
  return 'unknown';
}

 

The upshot is... on page load, your script will call to retrieve the apps and all their custom attributes, then your code can walk through the table rows for each app or API key, and then add elements (td's?) for each custom attribute you want to display.

As I said, not as easy as "check the box", but it is possible with some Javascript.

This is a bit fragile because of two things:

  1. it involves "walking the dom" and the DOM for the integrated devportal is not guaranteed to remain stable across updates of the developer portal.
  2. It uses fetch to call an undocumented portal API.

But this is an approach I have used for the past 22 months or so and it continues to work today.