Replies: 4 comments 16 replies
-
|
I do agree we could benefit from some pre-baked authentication helpers support for our supported frameworks. Would make embedding IDOM easier, especially when used in conjunction with #653 |
Beta Was this translation helpful? Give feedback.
-
|
sqlite is standard lib, so I'd think it's an okay backend for frameworks without an ORM. |
Beta Was this translation helpful? Give feedback.
-
|
Definitely something we can provide out of the box, but sqlite has similar limitations if you deploy multiple instances. |
Beta Was this translation helpful? Give feedback.
-
I think there is a misunderstanding. I do not suggest to put sessions in memory in the real world. I just did not want to complicate the example even more. I point out in the code and also in the README that it should be put in DB or a KV store. About the middleware: It is important that the session ID is always set. Even when the session data is empty. I do not know about Django's built-in
Maybe this is more a documentation issue. You could document how to integrate each framework's most popular server-side session framework with IDOM. For Sanic there is the already mentioned sanic_session. For Flask there is flask-session(Flask's built-in session works with signed client-side cookies). For FastAPI I could only find fastapi-session, but it seems abandoned. And for Tornado I only could find tornado-sessions, which is also abandoned. So both of you are fine with the "always set session ID on initial response and use server-side session" approach"? |
Beta Was this translation helpful? Give feedback.
-
The fact that everything is managed server-side does seem to fit well with IDOM. With that said, it's been a bit since I've had to implement lower level auth machinery so I'd have to do some research to be sure. |
Beta Was this translation helpful? Give feedback.
-
I thought that too.
Yes, me too. I did some research for the last two days after work. And because I found out that not all common approaches are equally secure or compatible with IDOM I was motivated to write up an example that might help others. Should you come to the same conclusion as I did, then a quick-win might be to add a high-level "how-to do auth" to the docs so others do not have to re-do the research. |
Beta Was this translation helpful? Give feedback.
-
|
I've created a very rough draft of what session management might look like in IDOM: #771 I don't think I'm satisfied with the interface, but it should get the idea across and could be used as a starting point for anyone interested in contributing this feature. |
Beta Was this translation helpful? Give feedback.
-
|
Given that I'm unlikely to find the time to implement this any time soon (we should about adding more to the 1.0 roadmap) the best option is to, as @phihos has said, write up documentation on how to do this for each builtin backend. I'm unsure whether we should have the documentation written for a 1.0 release though. I'm learning towards thinking we should since this seems like something that would come up pretty quickly for any new adopters. |
Beta Was this translation helpful? Give feedback.
-
|
@rmorshea, @phihos I really appreciate your efforts to show session / auth management. My current approach was to have the redirect endpoint (the endpoint you return to from the oauth service), return JS script which would set a cookie and redirect the client to an endpoint serving the app. eg. However this is not working. I never see the cookie on the /app request. Im not sure which direction is best and was hoping you could provide some direction. Options:
Im also struggling to split the boundary between what the server should do and what the browser should do. 🙏🏻 I would appreciate your insights and direction for how to best use IDOM for this sort of case. (small SPa + API, and avoiding creating two projects to do it) |
Beta Was this translation helpful? Give feedback.
-
|
@tylerhjones, at a glance this looks like Option 3 from #828 which, as the issue explains, has potential security vulnerabilities. I think our present recommendation is Option 2, where you render and handle auth using a traditional login page before redirecting to your IDOM app. In the long-run we want to implement Option 4, however we don't have a timeline for that yet. Let me know if you have any questions about how to make Option 2 work for you. I know @Archmonger has used it before in his project Conreq. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, ill take another look at the Conreq project to see what im missing when setting a cookie client side and not via a set cookie resp header, else ill have to do the hash to query and call and endpoint just to give a response with a set cookie header of the oauth token. |
Beta Was this translation helpful? Give feedback.
-
|
Which is also a bit weird as API calls via oauth are supposed to be a bearer token in the authorization header, not a cookie. |
Beta Was this translation helpful? Give feedback.
-
|
To help out, I believe the version of Conreq using IDOM is on this branch: https://github.com/Archmonger/Conreq/tree/app_store |
Beta Was this translation helpful? Give feedback.
-
|
For Conreq, I use Django's traditional HTTP views for my login page. If the user attempts to access an IDOM component that requires authentication, then a So IDOM doesn't handle any auth, only redirection to traditional auth views. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I hope this is the right place to ask this. Else I can also open an issue.
I am currently evaluating IDOM for a personal project and I like it a lot. You already have some nice examples helping me understand how to implement things with IDOM. One important aspect of my project is missing though:
What is the recommended way of doing authentication with IDOM?
The central problem to solve is how to establish a secure session over the websockets connection that is persistent across reloads.
A secondary objective is to achieve that with as little Javascript as possible.
I already scanned all discussions for solutions and what I found was either doing auth the "traditional" way and then redirecting to a page with embedded IDOM or doing auth completely inside IDOM and losing the session on reload. Both is not great. Maybe I missed something but I could not find a definitive recommendation.
I think I might have found a pattern how to do auth in IDOM via server-side sessions:
Implement a request middleware that sets a session cookie on the first response serving the initial HTML. That ensures the websockets connection always gets a valid session ID via
Cookieheader. Then withuse_requestwe can extract the session ID inside IDOM, retrieve the session data, check authentication info and either display a login form or the restricted page.I propose that pattern as recommended way of doing auth with IDOM since it is secure and easy to implement.
I already implemented a full example for Sanic (session and user persistence not included). In the README there is also a more in-depth explanation of my reasoning.
I am looking forward to get feedback from you people on this approach 🙂
Beta Was this translation helpful? Give feedback.
All reactions