Hi there,
Is it possible to use another table than the User table in Xano, to authenticate with Weweb either via the Xano auth plugin or rest api plugin
Hi there,
Is it possible to use another table than the User table in Xano, to authenticate with Weweb either via the Xano auth plugin or rest api plugin
Yes, and you manage that at the Xano level. Lots of plugins/tutorials/etc assume your authentication table is User, but you can set any table to be an āauthenticationā table from the settings for that table in Xano. Then you need to set up your function stacks to use that table after that.
Bonus: you can set up multiple tables for authentication. So itās allowed to have, say, vendors and customers in separate tables in a two-sided marketplace. It takes a little more work - these kinds of edge cases are definitely part of the hardest 5%.
@raydeck Interesting case you mention about vendors and merchants.
How to approach this in general.
If i saw it correctly you can use the Xano auth plugin only one time or am I wrong?
If this is correct should I then expand the function stack of the login endpoint to first check if a vendor exists and if not check if a merchant exist to retrieve the auth token. This approach would also imply that I use the same login form for both vendors and merchants.
Same question about signup. How should I distinguish between a sign up of a merchant vs sign up of a vendor?
My bias is to make logic more complicated on the Xano side so as to keep it simpler on the front-end. Thatās because Xano - like most backend solutions - is all about business logic, and doing more there is easier than in most front-ends, where have concerns about display, routing and interactivity. So your approach has an immediate appeal to me.
In general, give it a try and see how it works. You may discover that your particular use case or limitations mean you want to go a slightly different way. This is very hard to determine in advance, but taking some early steps can surface those issues and opportunities while they are still relatively cheap to address.
I think one challenge that needs clarifying how to handle this from Weweb team is, when using the Xano Auth plugin you are configuring it to only your primary; Login, auth/me, and Signup endpoints.
Then, when you have a private page, Weweb is automatically calling the auth/me endpoint with the current authToken that is stored in cookies.
If a user has been granted an authToken from a secondary authenticated table, then the automatic call to the primary auth/me endpoint will be rejected and the user will be logged out/redirected.
Unless Iāve mistaken something and there is a better way to do it; I have a few pages which I set to public, and manage the access to those pages by using a REST API action and calling the secondary auth/me endpoint myself.
I will try out authentication using the rest API. Should I store the token in a variable or better to use local storage?
What is it you are trying to achieve though?
My use of a secondary auth table is extremely limited (so take my comment with a grain of salt). Iām only using it for partitioning data of users who have commenced signup, but havenāt proceeded to becoming an āactivatedā user.
You can use the new workflow action āStore Auth Tokenā which will store the authToken in the ww-variable and in Cookies.
My use of REST API was also before the latest release which now enables you to change the headers within your Xano requests. So you can now pass the Authorization header to an endpoint that is authenticated using a different table.
I do believe is there are limitations with the current Weweb and Xano Auth Plugin configuration if you were to require having multiple authenticated tables widely across your app. You might need to explore your use case and find the limitations, wait for others guidance, or conceive a pattern where you manage more complex logic on the backend and keep a single user table for authentication.
Hi, you can build the auth yourself by using =>
You can fill the login/signup endpoint just to complete the setup without using it. But yeah, you still need to have a /me endpoint in your xano so we are able to get your user (for a given auth token) on app load and when we check if a visitor has access to the page.