I have an external database (Xano) hosting my data and I would like to use that primarily as my backend in Wappler. Xano allows connection to the database tables for Enterprise plans (which I’m not on) so I can only use API calls (external to Wappler) to login/logout users and secure the app access. I’m not a developer so going the typical db route as common on Wappler will mean I’ll lose out on the ability to create custom backend cloud functions / logic that Xano enables for me in a no-code fashion.
This is what I want to do / have been able to do. I could do with some assistance or direction:
Login user: Done. I used an external API request to Xano through Server Connect for that.
Store authentication token generated from signup: Done but stored this in a session variable on the layout page to be accessible to all pages (couldn’t figure out how the Globals worked). Is there a way to store the auth token privately without exposing it when you inspect a website’s code?
Restrict app/page access to authenticated users; otherwise, redirect to login page: I can’t seem to figure out both actions. I can’t use the Security Providers method because I’m relying on Xano APIs for all my authentication flows since that’s where my data is stored. Bubble was intuitive enough for me to do that with Xano’s APIs but I can’t figure out a way to do these things on Wappler.
Logging out a user: How would you accomplish this using external APIs? On Bubble, there was a way for me to clear the storage where I had the auth token stored. And then redirect to the login page if that storage was empty. I used this flow as well for when the auth token expired. But I can’t figure it out on Wappler.
Any ideas or assistance on #2, #3, and #4 will be much appreciated. If you don’t know the answers to all but only to just one, I’d appreciate that as well. Thank you.
Since you’re calling Xano’s APIs through server connect, you can store the auth token in an httpOnly cookie. In server connect, you can use the Set Cookie action and check the httpOnly box. Now the token (in the cookie) will be associated with every server connect call until the cookie expires, and it can’t be accessed by the client through javascript. So you’ll be able to pass it to the Xano api calls you make server side.
You can access the cookie by adding a variable to the _COOKIE global with the same name you stored the cookie under in the Set Cookie action.
To restrict app/page access to authenticated users you can add a server connect call to the page that checks for the presence of server side token cookie, and for better security, makes a successful call to Xano with the cookie to validate it. If the Xano call is successful, then the user is authenticated, if not, throw an error in the server connect (or pass the error from the xano api call, if any). On the client, you can respond to the error, by navigating to the login page.
To log out the user, if Xano has a specific Log Out api call, you’ll first make a server connect to call that api, and if it is successful, clear the server side token cookie by using the Remove Cookie action in Wappler.
If you do decide to store the token on the client instead, you can check Auth0’s recommendation for best practices.
Thank you very much for the detailed response, @that_cheeseguy. Your suggested approach worked! I’m very grateful. And thank you to @nomad and @JonL for your contributions as well.
I’m grateful for the community support here. Given the extensive and thorough documentation that no-coders like me are used to getting from Bubble, the lack of such for Wappler would have kept us from considering it. But as I look to rebuild on Wappler, the support and responsiveness from the Wappler community has been the defining factor in keeping me on track. Thank you very much.
This community is amazing – glad you found a solution that works!
After some time with Wappler, I think one reason for a difference in step-by-step guidance is because Wappler is much more open/flexible.
On Bubble, we had no choices with our database – either use the built-in option or use an API.
With Wappler, we can directly connect to all sorts of different databases to get the performance or features needed. That makes it a lot harder to document in step by step detail because the steps branch off so many places, I would think.
But there’s one pro when it comes to looking for help online beyond the community, which is that Wappler uses standard code… so you can often look at the code view on the element giving you trouble and search the web and find some explanation as to what is going on/what code to use to change it
Thank you. The standard code definitely helps a lot!
I think one area Wappler could focus one in its documentation without having to worry too much about the rate of obsolescence is to provide a good documentation / overview of the components and what they do.
So maybe not a full-fledged how-to-guide for now but something for each component like “Browser: this component is used to navigate to internal / external pages” with a quick demo / instructions of how to use it. Bubble has these with 1-2min videos or short text explaining what the components do.
It makes it easier for users to figure out what to use for what. There are a lot of components for instance that I don’t know what they are for and wouldn’t know unless someone pointed it out to me.
