Looking for guidance regarding configuring routers for a site with Authenticated and Unauthenticated areas

Help Requests
1

First, I have to admit, I’ve had trouble understanding routing beyond the basics. If it’s more complex than one router configured in app.ts to handle the whole site, it’s been hard to wrap my head around.

That said, I want to organize my site as such.

  • –Unauthenticated–
    • Forgot Username
    • Forgot Password
    • Log In
  • –Authenticated–
    • Home
    • etc.

TLDR; Is there an example I can look at that is set up similar to this design?

So far, we’ve had it working with ‘Log In’ being its own root and the authenticated views being under the ‘app’ root. Once authentication was successful, we’d aurelia.setRoot(PLATFORM.moduleName('app')) and everything was kosher.

Then I needed to add ‘Forgot Username/Password’ to the unauthenticated area. I created a component named ‘unauthenticated’ as home for a new router-view and configured a router just for it with the ‘Login’ and ‘Forgot’ views.

However, now when it authenticates and aurelia.setRoot(PLATFORM.moduleName('app') fires and I tell the router to navigate to ‘Home’ it appears to load the files, but the view never changes.

I’ve read a few posts like this one from Foursails (which is what we were doing originally) and this GitHub issue, and tried incorporating reset(), but I haven’t found the right combination getting it to work.

I feel like this is a major blind-spot in my skill-set and I’m coming up short when I try to understand it.

1 Like
2

maybe realworld will help?

2 Likes
3

Thanks, @brandonseydel! I will pour through it!

1 Like
4

While this is a great template, it doesn’t quite capture what I’m trying to accomplish.

The router-view for our authenticated views is wrapped by a menu and header that aren’t there for the unauthenticated views. The only way I can imagine making that work is to have a separate router for each area and swap the two depending on the authentication state.

1 Like
5

You can tackle this with many different approaches. Over the years my approach has changed and these days this is what I do for authenticated/unauthenticated areas.

  • Pipeline steps
  • Routes with configuration identifiers to determine if it’s an auth route or not
  • Occasionally, router layouts (configuring the route to use a specific layout)

The pipeline step controls whether the current user can access the route or not. It will check the route instruction to determine if it should do a check of the current user or just ignore the route, this is where I use auth: true or auth:false to determine if it’s an authenticated route.

Fortunately, I have a public project on GitHub that answers these questions. Here is a route config property using the above pattern I described here. I register an authentication pipeline step here, the code of which can be found here.

A lot of the code I have in my pipeline step can possibly be removed for your use case. On this line I get the current route object, this line I check if there is an auth property. These lines in my instance check if we do not have a logged-in user and it’s an auth route, we redirect them away. If we make it to this line we are allowing the route to proceed. The code prior to that is checking roles for the user (something you might want).

In my repository, I am not using the router layout trick I mentioned earlier because the logged-in admin panel uses the same design. However, the documentation for router layouts here is quite descriptive and will explain how you can leverage them. Give me a heads up if you run into any issues there.

2 Likes
6

Thanks so much @dwaynecharrington! I feel like a dope. Router layouts was the key I was missing. I scoured that routers page yesterday and glossed over it because of my rigid thinking.

Thanks again to @brandonseydel as well. Your template gave me some great ideas I plan to put to use.

2 Likes