search

archesproject / arches-lingo

Arches Reference Data Manager Application
GNU Affero General Public License v3.0
0 stars 0 forks source link

fixes user retention #56 #64

Closed chrabyrd closed 4 weeks ago

chrabyrd commented 1 month ago

This resolves: #56, #57, and #61.

It also raises interesting questions about session management and where user auth should live. Right now we're fetching the user for each page load. Not a huge overhead, and it gives the added bonus on knowing when a user has logged out via arches. Did another quick read re Django sessions and I'm wondering if there's a better way.

Also, right now as a placeholder for more complex logic we're manually checking if a user is anonymous or not. We're also defining whether a route should be "protected" in routes.ts . What about more complex logic, like if a page ( or component ) should only be rendered if a user belongs to a certain permission group? Moving the permission check to the page level feels more explicit, but possibly less DRY.

jacobtylerwalls commented 1 month ago

What about more complex logic, like if a page ( or component ) should only be rendered if a user belongs to a certain permission group?

Let's not get too fancy with the routing: the private routing is just there to ensure people get to the login page when they need to: it's the API that will enforce that permissioned users only see the data they can access.

chrabyrd commented 1 month ago

There's some not-great UX around the sign out button being visible to a not-logged-in user on the homepage now. IMO punt since this is a placeholder interaction

chrabyrd commented 1 month ago

Ah, I don't think we can just set requireAuth false on the root, because now when I navigate to the root as a logged out/anonymous user, I bypass login and go straight to the home page. I guess I'd rather just suppress the toast somehow.

Hmm I'm a little confused here, the user should get redirected to the login page when navigating to root, but shouldn't get a toast about it?