Goal: I want to setup an API resource with a predefined header value which is taken from {{current_user.metadata.MY_USER_ATTRIBUTE}}
I want to avoid to set this header in every app where I use this resource.
Steps: I've setup a new API resource and added a header with the value {{current_user.metadata.MY_USER_ATTRIBUTE}}
However, the API receives the header value "{{current_user.metadata.MY_USER_ATTRIBUTE}}" (plain string, not resolved).
Is it a bug or just misleading UI in the resource configuration editor (allowing me to add JS snippets wrapped in {{}})?
So the resource configuration does allow you to add JS snippets (e,g, environment variables), but current_user is available only within queries in an app, not a resource.
Is this as designed or a current shortcoming you will fix in the foreseeable future? Or do you a workaround (except of adding the header in every app where this query is used?
This particular pattern is definitely supported and works as expected in my brief testing. One thing to note - and the potential cause for the issue you're seeing - is that the JS interpolation will only work if the contained expression successfully evaluates. I'd start by double checking that your reference to MY_USER_ATTRIBUTE is valid.
I haven't yet tested on the specific version that you mention above, but will do so and provide an update here.
Hi @Darren , thanks for following up!
So I did some further checks and indeed it looks like it works now, but still seems a bit buggy:
So at first I had the user attribute set to empty string, and in that case the JS snippet didn't resolve and the API received the "{{...}}" string. When I set a non-empty value in the user attribute it worked! However, testing further, the interpolation fails when I put {{ (1+2).toString() }}. In that case the api receives again the string "{{ (1+2).toString() }}", instead of "3". Could it be that the JS snippets in the header settings in the resource configuration are not "real" but only allow plain references to e.g. current_user.metadata.xyz?
(I see that behaviour on both Cloud and self-hosted)
Yep - I saw the same behavior in my own testing. I haven't confirmed this, but my guess is that we specifically restrict the execution of arbitrary JS in this context for security reasons. Valid variable references should be fine, though! Will that be sufficient for your particular use case? Or do you need to perform additional variable manipulation?