4

I am trying to callout to the Salesforce Metadata service (ApexMDAPI) using Named Credentials. Using Named Credentials with the Apex Wrapper My goal is to use this credential with configuration in a managed package.

Here's my use case: I'm putting together a setup script for a managed LWC application. My app is using custom metadata which must occasionally be changed. (A series of configurable lists, to be specific) To do that, i need a first class sessionId or a Named Credential. (I'd rather not have a whole bunch of VF pages to do that part, and since Lightning doesn't provide the first class sessionId, I think I'm stuck with the Named Credential approach. After the pkg is installed, I have a VF screen which creates the Named Credential, so that Lightning components can use the Named Cred callout from lightning

I have successfully created the ConnectedApp/AuthProvider/NamedCredential records entirely with apex/Visualforce. The problem is that since I created the NamedCredential with apex, the initial authentication flow hasn't been triggered, and this can't be used in Callouts.

If I simply click "Edit"/"Save" on the new NamedCredential, then the auth flow will be triggered, and the credential works perfectly.

Is there another way that I can trigger this initial flow without requiring the user to edit/save the Named Cred?

In case you're wondering why I didn't just include the Named Credential in my original package, I've already tried that. The problem with that is the endpoint for the Named Credential still points to the org where the package was assembled. Editing the endpoint in the new org results in an unuseable Named Credential.

DaveS
  • 1,604
  • 1
  • 17
  • 20
  • 2
    You shouldn't need to do this, though? What's the use case for what you're trying to do? It sounds like an X-Y Problem to me. – sfdcfox May 09 '19 at 02:47
  • Here's my use case: I'm putting together a setup script for a managed LWC application. My app is using custom metadata which must occasionally be changed. To do that, i need a first class sessionId or a Named Credential. (I'd rather not have a whole bunch of VF pages to do that part, and since Lightning doesn't provide the first class sessionId, I think I'm stuck with the Named Credential approach.

    After the pkg is installed, I have a VF screen which creates the Named Credential, so that Lightning components can use the Named Cred callout from lightning. Better ideas are welcome.

     – DaveS May 09 '19 at 03:50
  • 2
    Session ID from Visualforce is API enabled , why not put a VF page that will give session id on the page. then use get content as to get that session ID? https://douglascayers.com/2018/09/10/calling-rest-api-from-lightning-components-without-named-credentials/ – Pranay Jaiswal May 17 '19 at 08:40
  • @Pranay Jaiswal - I already have that working for my setup scripts. This is for a managed package and I'd like to avoid using the VF approach more than one time. I'm not sure the Security Review folks will even allow the first VF page. It is by far, unquestionably, the easiest solution, though. – DaveS May 17 '19 at 16:00
  • This is well answered in this similar question: How to trigger Authentification of Named Credential created via Apex – DaveS Jul 10 '19 at 00:18

2 Answers2

0

From your question, it seems you just want to update custom metadata sometimes.

I would use Apex Metadata API. It's a new addition to Salesforce native api that allow creating and updating of Page Layouts and custom metadata. It serves your purpose and does not require Session Id hack or named credentials.

Pranay Jaiswal
  • 35,996
  • 16
  • 75
  • 134
  • There's a couple more metadata activities that I'm going to the API for besides just the lists. If it were just the lists, then I'd bite the bullet and switch to custom settings for that. I just didn't want to muddy up the water with all the details. – DaveS May 11 '19 at 18:41
0

Rather than swim upstream and try to overcome the issues of using "Named Credentials" callouts in a managed package, I've decided to use regular OAuth2 and simply manage my own tokens. This eliminates the problems with including the Named Credential in a managed package, and seamlessly eliminates any further setup reqs.

I'm going to store the access and refresh tokens in a Protected Hierarchy Custom Setting to keep them secure, and user specific. It's a little extra work, but it's the only solution I can come up with.

DaveS
  • 1,604
  • 1
  • 17
  • 20