5

I'm developing a custom content block component that will be used in multiple Business Units but share a single server. I need to be able to identify which Business Unit/Installed Package is making the request to the server but I can't seem to find anything in the request headers or body. I know Marketing Cloud Apps and Journey Builder Activities pass a JWT but I can't find anything in the docs about how to authenticate in the Custom Content Block.

Has anyone been able to find a way to use the request to identify the custom content block?

Thanks!

2

Followed AsinusAsinumFricat's theoretical solution with success. For others benefit, here's what I did:

  • Created an installed package containing 3 components:
  • API Integration, Marketing Cloud App and Custom Content Block
  • Set my Custom Content Block's Endpoint URL as my externally hosted app's root url
  • Set my Marketing Cloud App's Login Endpoint as my externally hosted app's login url
  • Ensured app's login route is a POST
  • Have app's main HTML page contain a style="width:0;height:0;border:0;" iframe with src= https://mc.exacttarget.com/cloud/#app/>>YOUR MC APP NAME HERE<<
  • App's login route would parse encoded jwt coming from SFMC SSO, decode it (using "JWT SIGNING SECRET"), then render a new HTML page printing the current business unit's MID to hidden iframe
  • Include a script tag on iframe HTML page to grab the MID, then pass it up to another iframe using parent.parent.postMessage(mid, >>YOUR APP'S ORIGIN<<); (passed to my app's main HTML page)
  • From here, I used AJAX to post the MID to the server, then look up API credentials in a database using the MID
  • With API credentials for the current BU, I could make a REST & SOAP calls to grab an access token then look up all the DE values needed to display in my Custom Content Block Widget
  • Once the calls came back, I rendered JSON to the AJAX callback function, then parsed and appended to the Custom Content Block Widget UI using jQuery.
  • With all those requests bouncing around, it would take about 6-10 seconds for the block widget to render.

I should note that while this approach succeeded testing in Chrome, my tests on FireFox always failed.

On inspection, I found my iframe was never loading. I suspect FF is blocking the iframe request for some reason.

Does anyone know why FireFox might block a block widget iframe in SFMC?

Thanks!

3

That's a great question. I asked the Architect of the Custom Block widget that very question, and he explained that you need to add a 'Marketing Cloud App' as a component to your Installed Package in Marketing Cloud and then add an invisible (one pixel) iframe to your custom block widget which is used by the Marketing Cloud app. In turn, this will let you retrieve the JWT payload.

He explained this in a user group presentation that you can review here (fast forward to 30 minutes in for this discussion).

  • Thanks Eliot. I took a listen to the presentation and it still leaves me with questions on how to access the JWT. It's my understanding that when the JWT is passed when the Marketing Cloud App is selected from the AppExchange dropdown. How does the iFrame make the POST call to the login route of the Marketing Cloud App? – michael.rockway Jul 23 '18 at 20:11
  • I'll run some tests and get back to you. – Eliot Harper Jul 24 '18 at 4:12
3

This one is tricky. Since the block framework doesn't send you to an SSO page, you don't get a JWT posted to your middleware.

One hacky way to go around this, but unfortunately the only way I can think of with SSO, is for the block to open up a 1*1px hidden iframe to its app's SSO page. That SSO iframe will then POST the JWT to the app's login endpoint (which should be the block's middleware) that can start the auth flow. So when the block is making API calls to the MC proxy-ed through its middleware, the middleware has the access to token stored for that session (or is in the process of authenticating).

  • block UI renders
  • block UI builds iframe to SSO page
  • iframe POSTs JWT to the block MW
  • block MW decodes JWT and requests an access token
  • block makes a UI call to its MW
  • MW has access token and proxies the call OR waits until it has the token

Please note that this is a theoretical solution. I have not tried and tested this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.