5

We are currently working creating a managed package which integrates with a third-party service through Canvas. The third-party service has different URLs for different users (similar to how Salesforce works with it's instances, i.e. na1, eu2, etc).

This is causing us issues as our Connected App definition must have a defined Canvas App URL.

We've come up with a couple of potential solutions, but we have no idea if these will work and/or pass the security review.

Option 1

Create a redirect page which all requests go to, which then takes some information passed in the Canvas context and uses that to redirect the user to the appropriate URL.

  • Will we have issues with XSS using this approach?
  • How do we get access to the context information in the page we redirect too, will simply including the relevant JavaScript libraries on the pages work?

Option 2

Use a Controller with a Custom Setting field to populate the developerName attribute on the apex:canvasApp tag, then as part of the post-install script get the user to create a Connected App, and then use the Custom Setting to refer to it.

  • Is it possible to have a Visualforce Page within a Managed Package that refers to things outside of the package in this way, or will it only look for the developerName within it's own namespace?
  • Will this pass security review? It will mean that we effectively have a lot of apex:canvasApp components that point to nothing until the Connect App is created and the Custom Setting exists.

Does anyone have any experience with doing anything similar? Will either of these approaches work and (importantly) pass the security review? Is there another option that we've not thought of?

Improve this question

1 Answer 1

Reset to default
3

In the end we didn't manage to come up with a solution for this on our own and ended up getting in touch with Jay Hurst (Senior Product Manager at SFDC). I've incorporated his comments with some thoughts of my own:

Option 1

This only works if the redirect you are performing is within the same domain, if you have to perform a cross-domain redirect then callback functions will not longer work between SFDC and your Canvas page (e.g. thesuccess callback for Sfdc.canvas.client.ajax).

According to Jay you can get around this by having a hidden iframe on the local instance which would embed your original canvas URL into their frame. You could then allow the cross site through your XOptions header and you could act as a man in the middle for requests.

Option 2

This works perfectly, and Jay suggested that there would be no problems in getting it through security review and that it has been the approach suggested to other clients. It means you don't have quite as simple an install for your app, but in our case this is not a problem.

We went for Option 2 in the end as having a more complicated install process is not an issue for us and the amount of plumbing to make Option 1 work seemed excessive.

Improve this answer
2
  • When you say you went with option 2 does that mean you created the canvas app in a post install script or that you gave the user instructions on how to create the app after the install? I'm asking because we're in the exact same boat.
    – cseaton
    Commented Jan 17, 2018 at 12:49
  • @csnullptr The product in question is not user-installed, and so it was a post-install setup for the team that does the installs/initial setup.
    – Alex Tennant
    Commented Jan 22, 2018 at 9:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .