ofj3kso
Auth guard
Thanks for clarifying the middleware behavior - the documentation could definitely use an update
I see what you mean about preload not truly preventing component mounting.
Essentially, it's a classic OAuth-style approach with JWT, incorporating logic that listens for changes. This reminds me of Firebase Auth, which seems to use a fast memory storage for tokens. This allows you to verify a token on the server by checking it against the stored memory and to create a WebSocket on the client for updates on signup, logout, and token refresh.
Anyway I don't want to bother you further, I really appreciate your time and insights. Thank you for the conversation.
8 replies
Auth guard
Tks for the rapid response. I agree with what you said, but I'm also seeking a solution that works universally for both Solid and SolidStart users. Plus my assumption is that auth guards should prevent component mounting entirely rather than running as side effects after components have already begun rendering. (Unfortunatly all the one I've seen so far use this approach)
I think the above code should just be able to handle the redirect logic, while the dev should handle the source of auth state. I can see people using something like Supabase client SDK (propably simpler apps) to handle auth state and other people fetching that info from the server (SolidStart).
One of my first tests was indeed using a middleware, but reading the doc here https://docs.solidjs.com/solid-start/advanced/middleware#limitations it's specified that "Middleware does not run on every request, especially during client-side navigations. Relying on it for authorization would create a significant security vulnerability".
Therefore I'm considering both the case the auth states comes directly form a server function or from a client lib that handles the auth
8 replies