7

I was trying to solve a problem with access and refresh tokens across multiple businesses in a single org and thought I would use Custom metadata Types.

The main reason was the field length can be > 255 which I need because the tokens are JWT tokens. The other reason was for the Relationship fields as the business is structured with stores (one or more) with devices (one or more per store).

I have everything working as an admin but where I am failing is:

As a regular non admin user

  1. Access tokens expired so need to use refresh token
  2. New access token is obtained
  3. Unable to update the custom metadata type with the new access token via apex metadata deployment

Deployment fails with "Invalid Cross Reference Id".

Attempted Resolutions

  • Assigning a permission set with "Customize Application" does not solve the issue
  • Ensured the class that performed the apex metadata deployment was set to without sharing

The only way I was able to get it to work was to assign the sys admin profile to the user

My question is:

  1. Am I out of luck here since I cannot assign system permissions to users just for this purpose
  2. Is there any way to update custom metadata types when initiated by code from a user without necessary permissions?

I realize I can use protected custom settings but I would need 5 access and 5 refresh token fields to store the data and since there is no lookup relationship I would need to manage all that via code which was mostly solved by Custom Metadata Types

Named Credentials will not work in this use case either...At least no so far as I can tell as I need to assign users to stores and the JWT auth is for the manager of the store not a single person. I could not see a way to make it work but....

I guess I just need validation there is no other way to do it currently before I go down the route of custom settings.

1

1 Answer 1

1

Given that there aren't Long Text fields on Custom Settings, I can see why you wouldn't go that route, but I don't think I would go with Custom Metadata over a custom object as a solution. Besides not having to deal with the problems of trying to do updates via the Metadata API, it would seem like the record-level access controls on sObjects would be an advantage over Custom Metadata.

You also don't get any value from what seems like biggest benefit of using Custom Metadata to store settings -- ease of deployment. That isn't a concern here.

I'd go with storing the keys in an encrypted long text field in a custom object, setting the security model to private, and giving each user ownership of his/her own record.

1
  • Unfortunately this is not acceptable to the security review team.
    – Eric
    Oct 6, 2018 at 4:52

You must log in to answer this question.

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