Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

attemptedTransition never persists #1660

Closed
drakej opened this issue Aug 23, 2018 · 12 comments
Closed

attemptedTransition never persists #1660

drakej opened this issue Aug 23, 2018 · 12 comments

Comments

@drakej
Copy link

drakej commented Aug 23, 2018

I've attempted to use the built in attemptedTransition mechanics and it's never worked. I tried with CookieStorage and AdaptiveStorage but it never sets this despite it running the code to do the cookies.write() call and the set('session.attemptedTransition') call. Neither call actually changes the contents of the cookie or the localStorage no matter if it's fastboot or not.

I'm not sure how this is supposed to work but I just extended your AuthenticatedRouteMixin and stored the transition.targetName myself in localStorage. Then did the transition inside of the sessionAuthenticated method on the Application Route which is uing ApplicationRouteMixin.

I'm baffled at how I can code this to work flawlessly in less than 20 minutes but I burned hours debugging the ESA built in solution. I couldn't even get set attemptedTransition myself because it gets cleared by the callback route before getting to the applicationRoute's sessionAuthenticated.

@drakej
Copy link
Author

drakej commented Aug 23, 2018

Forgot to mention. I'm using ESA 1.6.0 and ember 2.18.2.

@marcoow
Copy link
Member

marcoow commented Aug 23, 2018

What are you trying to achieve?

@drakej
Copy link
Author

drakej commented Aug 23, 2018

Just trying to redirect to the route that caused the initial transition to the login route.

@marcoow
Copy link
Member

marcoow commented Aug 23, 2018

So when you follow the docs, users should automatically be forwarded to the originally requested route if a transition was previously intercepted. That works both for the situation where the intercepted transition was triggered from in the browser or it was a FastBoot request. Check the demo app - this is using out-of-the-box ESA functionality only.

@drakej
Copy link
Author

drakej commented Aug 23, 2018

import Ember from 'ember';
import OAuth2ImplicitGrantCallbackMixin from 'ember-simple-auth/mixins/oauth2-implicit-grant-callback-route-mixin';

export default Ember.Route.extend(OAuth2ImplicitGrantCallbackMixin, {
    authenticator: 'authenticator:oauth2',
});

This is my callback route which is used when the auth server responds with the hash. Below is my Application Route.

import Ember from 'ember';
import ApplicationRouteMixin from 'ember-simple-auth/mixins/application-route-mixin';

export default Ember.Route.extend(ApplicationRouteMixin);

Here's my login route.

import Route from '@ember/routing/route';
import UnauthenticatedRouteMixin from 'ember-simple-auth/mixins/unauthenticated-route-mixin';

export default Route.extend(UnauthenticatedRouteMixin);

Then I also have a bunch of routes that are using the AuthenticatedRouteMixin. For example here's an route called about which just displays a static but protected about page:

import Ember from 'ember';
import AuthenticatedRouteMixin from 'ember-simple-auth/mixins/authenticated-route-mixin';

export default Ember.Route.extend(AuthenticatedRouteMixin);

Honestly I debated opening an issue because I figured this is going to be really difficult to reproduce. I may have to just grab your demo application and configure it against my auth source just to make sure it isn't related to simply redirecting from an external host.

@marcoow
Copy link
Member

marcoow commented Aug 23, 2018

so what are the exact steps to reproduce the error with that setup (e.g. in particular what's the first request that's expected to be intercepted and which transitions happen after that)?

@marcoow marcoow added the triage label Aug 23, 2018
@drakej
Copy link
Author

drakej commented Aug 23, 2018

I go to the about route to have it attempt the transition and then intercept and go to login (since it's a protected route) then after it logins it goes to the callback which then instead of retrying the transition from before, it always goes to index. Here's a log of what I see:

Navigated to http://localhost:4200/about
VM3547 vendor.js:65104 Preparing to transition from '' to 'about'
VM3547 vendor.js:65041 Transitioned into 'login.index'
Navigated to http://localhost:4200/login/callback
router.js:245 Preparing to transition from '' to 'login.callback'
router.js:182 Transitioned into 'login.callback'
router.js:245 Preparing to transition from 'login.callback' to 'index'
router.js:182 Transitioned into 'index'

@drakej
Copy link
Author

drakej commented Aug 23, 2018

Tried to run the dummy application but it resulted in

ERROR: [Errno 2] No such file or directory: 'install'

I was following the guide from the README.md

git clone https://github.com/simplabs/ember-simple-auth.git
cd ember-simple-auth
yarn install && ember serve

yarn install causes the error and unfortunately I'm not familiar with what that command actually does.

@marcoow
Copy link
Member

marcoow commented Aug 23, 2018

try npm install instead of yarn install

@drakej
Copy link
Author

drakej commented Aug 23, 2018

That worked, and I got to learn more about yarn in the meantime. So I was able to test and the issue definitely the external redirect. You don't need to stage this. Use your demo application, go to the protected page so it redirects you to login, then use Google OAuth2 and login. It takes you back to index which means this problem exists for any external callback OAuth2 with the returned hash.

@pauln
Copy link

pauln commented Aug 31, 2018

I've been scratching my head over this, too. I started working on implementing the redirect logic myself, but as part of the process, came across documentation / references to session.attemptedTransition which suggested that it should already work... then found this issue.

I can also confirm that the Google OAuth2 login option in the demo app does indeed suffer from this issue, while the Resource Owner Password Credentials login option redirects to the protected page after login as expected. As per the title of this issue, it seems that it's not being persisted - so once the user is redirected to the external login page, the transition is gone.

@marcoow
Copy link
Member

marcoow commented Mar 21, 2019

cleaning old issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants