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

Handle harvester loading in a route guard to better handle the unauthenticated method. #11373

Merged
merged 2 commits into from
Jul 9, 2024

Conversation

codyrancher
Copy link
Contributor

@codyrancher codyrancher commented Jul 5, 2024

Summary

This is done by providing a 404l page which is authenticated.

Fixes #11350

Technical notes summary

We will still need the fix from be1e27b for prod.

Areas or cases that should be tested

404 routing.
Harvester routing.

Screenshot/Video

Regular 404:
https://github.com/rancher/dashboard/assets/55104481/5d3d2fc8-0cbd-4d20-99e0-59dda8a0d8e3

Harvester 404:
https://github.com/rancher/dashboard/assets/55104481/310f10e4-6881-402f-8952-a55f9b846d82

I noticed a flicker of the resource page on this one. I can only reproduce this on the harvester cluster but it's in master and unrelated to both this PR and harvester itself. If anyone else can reproduce this I'll resolve it as a separate issue.

Checklist

  • The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
  • The PR has a Milestone
  • The PR template has been filled out
  • The PR has been self reviewed
  • The PR has a reviewer assigned
  • The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
  • The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

@codyrancher codyrancher force-pushed the harvester-guard branch 2 times, most recently from b86c891 to 93cd9e5 Compare July 8, 2024 06:12
@codyrancher codyrancher changed the title Handle harvester loading in a route guard to better handle the unauth… Handle harvester loading in a route guard to better handle the unauthenticated method. This is done by providing a 404 catch all page which is authenticated. Jul 8, 2024
@codyrancher codyrancher changed the title Handle harvester loading in a route guard to better handle the unauthenticated method. This is done by providing a 404 catch all page which is authenticated. Handle harvester loading in a route guard to better handle the unauthenticated method. Jul 8, 2024
@codyrancher codyrancher added this to the v2.9.0 milestone Jul 8, 2024
}

export async function loadHarvester(to, from, next, { store }) {
if (!routeRequiresAuthentication(to) || to.name !== '404') {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only execute if authenticated and on a 404 page.

path: '*',
name: '404',
component: () => interopDefault(import('@shell/pages/404.vue')),
meta: { requiresAuthentication: true },
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We specifically needed this component so we could make sure authentication would be run on 404s.

import Brand from '@shell/mixins/brand';

export default {
mixins: [Brand],
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need this to reduce the flicker in dark mode.

Comment on lines +6 to +9
beforeMount() {
this.$store.commit('setError', { error: new Error('404: This page could not be found') });
this.$router.replace('/fail-whale');
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If route guards don't redirect us we should go to failwhale with the error message we used to emit in the render() method of entry-helpers.js

Comment on lines -198 to -203
// If no Components matched, generate 404
if (!Components.length) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will no longer ever be true because our 404 page will match if nothing else will.

@codyrancher
Copy link
Contributor Author

I'll open for review once tests pass again. Looks like we may have had a node version change. This change was passing all unit and e2e tests on friday.

Copy link
Member

@richard-cox richard-cox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When testing I saw all nav guards start in order, but finish out of order. This makes me very nervous, but i couldn't find any specific bugs. We should pay attention to this, in particular things like multiple api requests to the same endpoint on load, or extra schema missing warnings. Just as a tidy up I added async/await to the beforeEach hooks (though i don't think vue router awaits them).

I also de-harvester'd the navigation guard names.

Edit: Also re-based to resolve conflict given something merged earlier in the day

try {
// Handle the loading of dynamic plugins (Harvester) because we only want to attempt to load those plugins and routes if we first couldn't find a page.
// We should probably get rid of this concept entirely and just load plugins at the start.
await store.dispatch('loadManagement');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes me nervous, we're calling this before some of the normal setup stuff in the auth middleware. It's quite dependent on the order the nav guards run as well, more in PR review comment

@codyrancher
Copy link
Contributor Author

I think we need to be really clear what the issue is because the way that you've described it and the commit you added makes me think there's a misunderstanding of how navigation guards work.

Just as a tidy up I added async/await to the beforeEach hooks (though i don't think vue router awaits them).

You're right, vue-router isn't awaiting them. It's waiting for the the hook passed to beforeEach to call next(). This change doesn't actually safeguard against anything.

When testing I saw all nav guards start in order, but finish out of order.

The call to next() is what will call the next navigation guard in the list. You will not see the caller finish until the callee finishes because it's going in stack order.

function b() {
   console.log('b');
}

function a() {
   console.log('a')
   b()
   console.log('c')
}

a();

We will see abc printed which indicates a() finished executing after b() finished. This is the exact behavior we should see with the beforeEach navigation guards. If you're seeing out of stack order then we do have a problem and we should address that. But that's not what I noticed while working on this.

@codyrancher codyrancher marked this pull request as ready for review July 9, 2024 04:02
@codyrancher
Copy link
Contributor Author

I'll go ahead and merge once master has all tests pass or we decide to skip.

Richard added 2 commits July 9, 2024 07:56
…enticated method. This is done by providing a 404 catch all page which is authenticated.
@codyrancher codyrancher merged commit 0e9709b into rancher:master Jul 9, 2024
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants