You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I moved the last comment from #353, because it makes more sense as new discussion:
As we don't have too many backend folks yet, I think if you just do backend work in your project and stay in touch with me if you have ideas, well, that would be great!
Keep in mind auth in a website produced by a framework like Kobweb is tricky, because you download the whole site at once. You can contrast this to using ktor directly, where you could add auth to routes on a case by case basis, because the user has to hit the network each time to change pages.
My notes are a little sloppy here, but you can take a look at #254 to see a few more details of what I was thinking.
In Kobweb, I suspect auth will be best served by 1) integration on the frontend side and/or 2) an awesome auth library on the backend (plus some manual labor to check auth in each relevant API request)
frontend
Despite the user downloading the whole site, we could still have logic to redirect to a different page if credentials are not found.
It's possible auth is handled by some @Auth annotation that I haven't really thought too deeply about yet.
backend
With a backend approach, I think you'd let users navigate to any page, but on each page that requires auth, you'd make an API call first to check if they're logged in, and if not, reroute to a login page then. (You can use local storage or session storage to cache a login key).
And then, don't ever return data from any of your protected API routes if the user doesn't pass in identifying keys in the get params or post body.
It's fuzzy in my memory now, but I think I do something like this a bit with kobweb create examples/chat
Of course, open to hear any other ideas you have! Or if you find any other feature missing from the backend that you think would be interesting to work on.
First off, thank you for the detailed explanation.
I have prior experience with building Ktor backends and have worked on setting up various authentication schemes. I agree with your general approach: it's perfectly acceptable for the frontend to download all at once, as the actual authentication checks are usually required at the API endpoints. So the user getting access to the layout is not a major concern as long as the data and actions are properly authenticated.
I'm familiar with the examples/chat template, as I used it as a base for my current project. In it, I noticed that while the frontend does keep track of the login status, the backend doesn't take the authentication status into account.
For now, I've decided to hold off on implementing authentication in my project, since it's not a pressing requirement for my current use case. However, I'll definitely revisit this topic in the future.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I moved the last comment from #353, because it makes more sense as new discussion:
First off, thank you for the detailed explanation.
I have prior experience with building Ktor backends and have worked on setting up various authentication schemes. I agree with your general approach: it's perfectly acceptable for the frontend to download all at once, as the actual authentication checks are usually required at the API endpoints. So the user getting access to the layout is not a major concern as long as the data and actions are properly authenticated.
I'm familiar with the examples/chat template, as I used it as a base for my current project. In it, I noticed that while the frontend does keep track of the login status, the backend doesn't take the authentication status into account.
For now, I've decided to hold off on implementing authentication in my project, since it's not a pressing requirement for my current use case. However, I'll definitely revisit this topic in the future.
Looking forward to collaborating further!
Beta Was this translation helpful? Give feedback.
All reactions