@Steptornetta.

What data source are you trying to connect to that you’re building the authenticator in Apex?

Custom Apex Authentication (from Skuid Docs)

This option is currently only used internally to support the Sharepoint data source type’s custom authentication process.

Unfortunately, there’s not much I can direct you to in the way of Skuid resources except for that one sentence… hopefully you can find some clues in Apex docs / developer forums and in the documentation for the data source to which you’re connecting.

Hi @Anna_Wiersema - thanks for responding!

This is just for a REST data source. I’m not actually using the Custom Apex Authentication which is what you linked.

I understood the Apex merge variable (Apex Merge Syntax) to be different than the Custom Apex Authentication.

I think the resource you linked applies to creating an auth provider with the Custom Apex Authentication Method.

I am trying to return a value to my data source via Apex merge syntax.

Maybe I mis understood these release notes: Edinburgh — Skuid v16.0.2 Documentation

They seem to mention the following

• Use Apex to provide authentication values in data sources: (SFX only) Apex, Salesforce’s server-side programming language, can now be used to return values used in authentication requests from Skuid’s proxy.For instance, some authentication tokens may be longer than 256 characters or saved in a different secret store than Skuid. With this feature, you can write an Apex class that retrieves and returns these values as a string and use it with the $Apex merge variable.

Hey @Steptornetta! I have good (?) news: this may be working despite what you’re seeing. The merge variable value is injected server-side through our proxy, so you won’t see it in network requests during debugging. This helps keep these secret values secure.

A few suggestions to make sure everything is working as intended:

• Ensure the Apex proxy is enabled on the data source. Skuid won’t be able to inject the value otherwise.


• Try using system.assert to verify your code’s execution. A line like system.assert(false,'The class was called'); will cause an error on your Skuid page when the model connected to this data source is queried, so that confirms that the Apex code is executing.


• If both of those action items seem like they’re working, consider setting up the auth process as expected for the service you’re connecting to. Even if the network requests tab doesn’t reflect it, the merge variable may be injecting the proper value as expected.

Based on this thread, I’ll update our docs with a clear note about the value not displaying client-side. I’ll also be updating the given example to illustrate how to access the class given in the sample code (i.e. {{$Apex.SecretsValueProvider}}). I’ve got some other priorities right now, but I’m hoping to have that update out soon.

Hope this helps!

Hey @Cody_Taylor,

Thanks for looking into this for me. I wasn’t able to get any specific error message to be returned back to my page when testing, so I think the apex not actually triggering is most likely the issue.

I also additionally tried to just directly return the necessary token for authentication directly from the Apex class and that did not seem work either. I tried to do some additional testing with permissions to the Apex class that might be preventing it from being called (i.e provisioning the user running the page access to the Apex class) but that did not produce any different results.

I added some screenshots below of my findings:

• I double checked to make sure the DataSource (DSTest) I was testing with is using the Apex proxy.

• Authentication setup for the Data Source references {{$Apex.SecretsValueProvider}}

• Updated Apex class with the fail assertion.

• DSTest model setup from within my page. Setup a button to trigger a query on the data source on action.

• Auth error returned to console. I think in this instance I would see the System.AssertException: Assertion Failed: The class was called error?

• Not sure if there is a difference in expected behavior in calling the Apex class from a merge tag within a auth provider vs. separate authentication url but that didn’t seem to trigger anything differently.

Hrm, I’m also seeing some interesting behaviors trying a similar use case. I’m conferring with some folks internally to safety check some things… Updates soon

Just want to let you know we haven’t forgotten this. Our team is still investigating, and we’ll get back to you when we know more.