Problem with error redirections (auth.interceptor.client.service.js)

[0xNacho]

For some reason, when you get an app error you are unable to get back to the previous page (because of interceptor catch the previous error and redirects again to the error page).

[mleanos]

@0xNacho Can you provide a step by step on how to reproduce this issue?

Also, what type of app error are you referring to?

[wansco]

I just created an issue (#1086) that is loosely related to this. I think the problem is that auth.interceptor caught some sort of a login issue on the previous page, so going back only re-triggers that 401/403 error which then dumps you back through the rejection to either the signin page, or forbidden.

The signin page makes sense (I haven't checked the latest versions, as I know there was some code added to redirect to the previous page added recently)

The /forbidden page is causing a lot of confusion, because that is either "legitimately forbidden, but still logged in" or "forbidden because you were logged out on the server, but the client-side still thinks you're logged in"

see issue #1086 for steps to get you into the latter condition on the /forbidden page.

[trainerbill]

@wansco Can you pull in the JWT PR and see if it fixes this?

[wansco]

I think this might still be an issue, although the forbidden part is gone. Basically it doesn't appear to be respecting the server policy. Steps to reproduce:

• Clean install
• Modify modules/articles/server/policies/articles.server.policy.js line 34 (change the role 'guest' to something else i.e. 'xguestx'. This should eliminate views from non-users or non-admins)
• Go to the List Articles page (when you are NOT logged in)

Before, this would send you to /forbidden and the back button would loop you back to the /forbidden page.

Now it appears that the page is served up without an issue... but the modified roles defined in the server policy should prevent non-logged in user

I haven’t thoroughly investigated this, but I did just test the before and after behaviour described above.

[mleanos]

I'm seeing the correct behavior on the latest master branch; also, checked on the JWT PR branch & @wansco's steps reproduces the described behavior.

@trainerbill What changes in the JWT PR would be causing this?

[trainerbill]

I really don't get it... why would you want to change the guest ACL there? Just remove the get from the / route, or require the user role for it. Why does this happen in JWT, because the isAllowed is gone as they are public routes... I guess I can add it back, I just figured if they are public routes why even go through the ACL check... but now I see your point as someone may want to limit it.

[wansco]

Sorry, that was just a test for an unauthorized route. You wouldn't do that in practice, but that was the easiest way I came up with to simplify the "steps to repeat." Also, I wanted to test the user roles, rather than the route.

Good work on the JWT by the way.

[mleanos]

@trainerbill It's only public (server-side) because the ACL allow's it on the adhoc "guest" role. The steps demonstrate that the ACL policy isn't being applied correctly in that case.

[trainerbill]

@mleanos fixed it already

[mleanos]

@0xNacho Can you verify that this issue has been resolved in the latest master?

[lirantal]

I can't reproduce this either by manual steps in the client-side, I just get redirected to the login page.

[lirantal]

Closing this issue.