Skip to main content

Hi, 

I have a REST model that is integrating with a 3rd party system (Snowflake) that requires I generate a JWT token and include it in the HTTP headers. 

I have an Apex class in Salesforce that is correctly generating this token (I can confirm this using Postman), but I can’t seem to get it added into the Common HTTP Request data section. I’ve tried using the {{$Apex.ClassName}} merge variable and having the class implement the skuid.Utils.MergeValueProvider interface but that doesn’t seem to work? 

I also see there is a Custom Apex Authentication option in the Auth providers, but I don’t see any documentation anywhere on how I can leverage that and I’m getting Apex errors when trying to implement the recommended ModelDataSourceAuthProvider interface. 

Is there a better way I should be dynamically inserting this header value from Apex? 

Bump. Any ideas I can test?


Hey @BWind - Have you enabled the Proxy with this data source?


This is the documentation that talks about how to insert merge variables form Apex into the HTTP Requests.
https://docs.skuid.com/latest/v2/en/data/authentication-and-skuid.html#on-the-apex-merge-variable


@annajosephine Thank you for the response! 

1. Yes, I have toggled the ‘Use Proxy’ to true for this data source. 
2. I have followed the directions in the linked document and cannot see that the class is being called. I’ve also added the suggested assert statement and still do not receive the error. 

system.assert(false,'The class was called');

The only error I receive is “Bearer token is missing in the HTTP request authorization header.” which is where I’m trying to use the merge variable:
 


Can you confirm that the $Apex merge variables should be able to be used in the common request headers section? 


This thread outlines almost the exact same issue I’m seeing, except that they are inserting it into the body whereas im inserting it into the headers. However, the experience is very similar. Do you know if there were any updates out of that convo? 


@annajosephine Just checking in - any thoughts on if this is an existing bug / issue? 


Just noting that I was never able to solve this issue with passing a dynamic header. In our case, I was able to work around the issue because the API we were integrating with is custom built by our team, so I could pass the value as a query parameter. 


Reply