| 21 Mar 2024 |
 James | There's probably a good way to do what I did with a context but I couldn't get it quite right due to juggling too many states | 09:11:43 |
 Brynn | Would it be a bad idea to store expiry datetime in the database alongside the session information? Then the client polls the server every x time. When you get within x time of the expiry a notification pops up. | 09:15:09 |
| Brynn | Would that help with limiting states? | 09:15:34 |
| Brynn | (Still very new to statelessness) | 09:15:50 |
| James | Well my particular issue is frontend state, you have to store information on what information is required for elevation, and which dialog is showing, etc. | 09:16:34 |
| Brynn | Wdym. Like what the page looks like when the user asks to auth so after they auth the page looks the same? | 09:17:39 |
| James | It gets a bit more complex when you give admins a few options for how to enforce it. But yea | 09:17:40 |
| James | We store the expiration in the session data | 09:17:47 |
| James | Well there's the original "open dialog" callback which you keep track of, I think from memory there are 2 or 3 total dialogs, there's one for just the code, there's one for the code or 2FA, and one for 2FA. You do a request to see if a user has elevation information in the session and it's not expired, if it's not expired the callback is called, otherwise the appropriate dialog opens, and if needed the appropriate second dialog opens, then the callback is called provided there are no errors. | 09:20:14 |
| James | Actually pretty sure we dont' store a callback, just the "opening" state of the final dialog. | 09:20:59 |
| Brynn | Ah OK. I haven't really done much with nested modals. Should be fun! Anyway I'll mock up what I have in mind tomorrow. | 09:21:41 |
| James | Maybe that's what I needed to use a context now that I think about it | 09:21:53 |
| James | They're all separate, it's just a flow them haha, felt that was the simplest means to get it right | 09:22:24 |
| James | * Maybe that's what I needed to use a context now that I think about it (a callback) | 09:22:46 |
| James | * Maybe that's what I needed to use a context now that I think about it (a callback, pass it to the context to call after it's done with "auth" or discarded on error) | 09:23:03 |
| Brynn | 
Download image.png | 23:23:23 |
| Brynn | just sharing what I have so far. | 23:23:24 |
| Brynn | talked to a friend and he suggested icons next to the navbar items and that the navbar should collapse like on the users settings page | 23:23:56 |
| 23 Mar 2024 |
| James | Nice reference design, GitLab when you generate a client shows the client id, and has a client secret which you can't see but you can copy or uncover and it warns you about only getting to see it once. | 06:53:10 |
| James | I'll show some images | 06:53:17 |
| James | 
Download image.png | 06:55:19 |
| James | 
Download image.png | 06:55:45 |
| James | View after returning to the app | 06:55:52 |
| Brynn | the actual item display is taking a little longer than I was expecting, Im trying to do it all in react for some practice and Im having to learn at the same time. | 07:01:46 |
| James | Are you looking at the examples on the MUI website? | 07:03:11 |
| Brynn | yeah, I'm thinking the actual item display will be an accordion, same with users | 07:03:54 |
| Brynn | * yeah, I'm thinking the actual item display will be an accordion, same with users list | 07:04:27 |
| James | For reference we can take our time, I had planned on doing that anyway, and pushing to get another feature release out before this is merged (so we can hopefully have more to add to it). | 07:07:28 |
| Brynn | In reply to @james:authelia.com
sent an image. cloudflare does the same thing when you create an api key. | 07:18:13 |
| James | It's a common pattern | 07:18:28 |
