Restricte route by user role, possibly a middleware?
Hello, I would appreciate some assistance from more experienced web developers, if possible.
My issue revolves around user roles and restricting access to certain routes based on those roles. While I've successfully hidden the navigation buttons, there remains an issue: if a user types a restricted route directly into the URL, they can still access the associated component, which is something I want to prevent. Currently, I've implemented a solution where if a user attempts to access a restricted route, they are redirected back to their previous route in history. However, this solution isn't optimal as it causes a momentary loading of the component before the redirection occurs.
- Im using SolidJS SPA + Go server, not SolidStart.
Any insights would be greatly appreciated.
9 Replies
Presumably, if you have user roles etc. then you're running on a server?
The server should be doing validation on anything that the component tries to do anyway (and rejecting it if not authorised to do so) - the momentary loading of the component is then not a huge deal.
You can't implement purely client-side validation because you fundamentally can't trust the client
Not, this part is running on the client.
My server is a written in Golang, with the dashboard made in solid.
I'm already checking for auth on the server on each request using a middleware.
Ideally i'd like a way run a function before a route is mounted, kinda like a middleware, but on the client. This way i'd be able to check for auth and decide if i mount the route or redirect him, before the protected route is mounted.
Ok so your server is already doing validation to make sure that the client can't do anything it shouldn't, yes?
In which case your component trying to load before the redirect is entirely unimportant, given that a well-behaved user can't get there anyway
yes, its a json api, if he doesn't have the specific role, he cannot access the resources.
So them (partially) loading a protected route is completely fine
And given that if they're loading a protected route they shouldn't have access to anyway they're not behaving, does it really matter if they get a slight FOUC?
IMO there's no point putting time into improving the UX of an operation that well-behaved users, by definition, can never encounter
yeah, thinking this way your point makes sense.
if a user types a restricted route directly into the URL, they can still access the associated component,Conceptually, with route-driven data loading (in contrast to component data-loading) the router could inspect the returned JSON payload to determine whether the user is authorized (in the simplest case a 401 from the server) and then perform a redirect to a fallback route in case of an unauthorized access. The component level alternative is to have the component throw an error when it doesn't get the expected data and have the nearest
ErrorBoundary render fallback content.Interesting, i'll try this
If you are using Solid-Router you can
throw a redirect() instead of an Error to render an alternate route.