auth0/auth0-vue

appState.target has undocumented dependency on using Vue Router

jrubinator opened this issue · 6 comments

jrubinator commented

Checklist

  • The issue can be reproduced in the auth0-vue sample app (or N/A).
  • I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
  • I have looked into the API documentation and have not found a suitable solution or answer.
  • I have searched the issues and have not found a suitable solution or answer.
  • I have searched the Auth0 Community forums and have not found a suitable solution or answer.
  • I agree to the terms within the Auth0 Code of Conduct.

Description

When using a Vue app without a Vue router, appState.target is ignored post-redirect (instead of being followed, per https://github.com/auth0/auth0-vue/blob/main/FAQ.md#3-user-is-redirected-to--after-successful-sign-in-with-redirect).

Instead, you will always be redirected to /

Reproduction

  1. Update https://github.com/auth0-samples/auth0-vue-samples/blob/master/01-Login/src/components/NavBar.vue#L108 to something like
      login() {
        auth0.loginWithRedirect(
          {
            appState : { target: 'post-redirect' }
          }
        );
      },
  1. Comment out use of Vue Router in https://github.com/auth0-samples/auth0-vue-samples/blob/master/01-Login/src/main.ts
app
  .use(hljsVuePlugin)
  //.use(createRouter(app))
  .use(
    createAuth0({
  1. Configure your auth0 info and start up the app
  2. Log in

At this point, you will be logged in to http://localhost:3000/, rather than http://localhost:3000/post-redirect

Additional context

I think the source of the issue is https://github.com/auth0/auth0-vue/blob/main/src/plugin.ts#L165-L180, where we update the window history to be / but do not push a new route.

auth0-vue version

2.2.0

Vue version

3.3.4

Which browsers have you tested in?

Chrome

frederikprijck commented

Thanks for reaching out. I can see what's going on, but curious to learn more about your use-case.

Typically, appState.target is used to navigate to a route in your Vue application. In your case, your Vue application has no routes, yet you want our SDK to redirect the user to a different route.

Can you elaborate on the scenario you are trying to cover?

We could push the correct target instead of / when calling replaceState, but this will break people using a router. So we would need to do it in the follow case:

if (router) {
  router.push(target);
} else {
  window.history.replaceState({}, '', target);
}

However, this can become complicated when the user wants to use #post-redirect instead of /post-redirect. Definitely want to see how we can solve this, but would like to understand more about your use-case.

jrubinator commented

Sure! I have a CDN that is serving a couple different applications. They're mounted at different endpoints, like my.cdn.com/app-1 and my.cdn.com/app-2

One of these applications is actually a small demo site (let's say my.cdn.com/app-1), to support another application that expects to be embedded in an iframe. The embedded app in turn expects to be passed an auth JWT.

So the demo site allows users to log in at my.cdn.com/app-1 and then after login, redirects back to my.cdn.com/app-1, where it can then set up its embedded iframe. However, because of the rewrite, I end up at the root my.cdn.com, which eg. won't work upon refresh.

FWIW, I was able to work around this fairly easily by adding a dummy router, so this isn't stopping me from using auth0, and it's not causing too much pain now that I recognize the cause.

frederikprijck commented

Thanks for that feedback. I am going to leave this issue open so I can get back to this and see if we can solve this, or add something to the readme.

itzstatic commented

Just leaving this comment here as a related issue I experienced:

I am using Vue Router but was still having trouble getting my SPA to redirect to the intended protected page after handling the redirect callback.

It turns out I had to install router on our Vue instance before installing this plugin. Doing it in the opposite order will leave the app redirecting to /!

It would be nice if the logic in __checkSession could somehow be moved out of the plugin install and into say a deferred nextTick type of handler on app startup, seems like it would avoid dependency registration order problems, and also let that code throw exceptions.

frederikprijck commented

@itzstatic this is by design and explicitly called out in our examples, see : https://github.com/auth0/auth0-vue/blob/main/EXAMPLES.md#protecting-a-route

Would changing the order as mentioned in there not work for you ? If so, can you elaborate why not?

  • 👍1
frederikprijck commented

I'm going to close this issue and leave things as is. If anyone comes up with the same issue as mentioned by the OP, please let us know and we can reconsider.

However, given users can mock the router and work around it (and the people using our SDK without a router seems to be rare), we won't action this at the current time.

Regardless, thanks for taking the time to report this!

  • 👍1