We are using the custom token based auth plugin. The field for
user-endpoint
needs to be different in production vs development. We can’t figure out how to apply a formula or otherwise make this value dynamic. Can you please help us out here?
I think I spoke with @Alexis about this quite some time ago, we were talking about a wwLib method/variable, that can detect whether you’re in the editor, and based on that, you could maybe make your different scenarios.
What I think would be the simplest hotfix, is exchanging the scenarios before publishing, and then turning the testing keys back on for further editing.
It already exist @Broberto, you can find the value in the data explorer.
But the issue here is not accessing the information, it’s allowing to bind some settings inside plugins. Historically you can’t bind anything inside plugin settings. We started to allow it for some Xano properties (global headers).
And so, to have a specific configuration for each environment we have to build specific form with one input by environnement. For example in Xano you can choose the branch for the editor, staging and prod.
Here @isaacmartin need the same thing for the Token Base Auth plugin. To be able to define a different endpoint by environment.
I’m sorry, I don’t think we have a workaround for you at the moment. I think it’s something we will handle in 2024 and develop a core system for environment variable, or implement multiple tabs (editor/staging/prod) in every plugin settings.
But be aware you may be able to build a secured app without our Token Based Auth plugin. If your data are already protected by your API and you dont use any static collection page with sensitive data, you could achieve the same level of security by doing your own auth logic.
- Create two global variables, isAuthenticated and user, toggle preserve on navigation + localstorage on both
- Create a global workflow for the login, and update theses variables
- Create an app workflow (app settings → workflows), on page load → redirect to login page if isAuthenticated === false or depending of the user information like roles.
We are creating a proxy on our api which will forward requests to the correct destination as a workaround.
I recommend creating a standard concept of an input field which applies throughout your product so that all input fields have access to the “formula” (dynamic) functionality to make it easier for customers to self-serve.
1 Like
It’s already the case, the issue is people may try to bind things that do not exist during the plugin initialisation or execution time, and some settings are used by our backend and cannot evaluate the formula.
But yeah, one idea I’m exploring is implementing a lifecycle based explorer, so the formula data explorer only show what will be available depending on where you’re binding things, and so we can make everything bindable without having to let people figure out if their binding will works.
To be honest there is no technical limitation, it’s mostly an UX and prioritisation issue! Thanks for your suggestion 