Option to choose extension boot order

[lukadriel7]

Hello again, is it possible to add an option to choose the boot order ? At the moment the extension boot is added using push putting it after the boot files defined in quasar configuration. If there were an option to choose whether to unshift or push the boot file, it would help. Specifically when using a router-auth boot file to determine if the user is logged in at each route navigation.

[smolinari]

How are you logging in the user? I ask, because normally you'd need to contact the server first to validate credentials and for that, you need the GraphQL connection.

Scott

[lukadriel7]

I am using laravel sanctum and I check the user log status based on the cookies. The user logs in from a standard login page. I created a boot file that check before each route navigation if the user is connected.

[smolinari]

And, how do you check if a user is "connected"? Somehow you need to connect (via GraphQL?) to the server, right? So, the first thing should be, send a request to the server about the user at hand (and validate access token/ session) and if all is well, the user can continue. If not, they get redirected to your login page. In other words, your SPA should access the API server first (to authenticate the user as "ok" or not), then route the user accordingly. The boot sequence should be fine.

Scott

[Arsync]

GraphQL might not be a part of authentication process, as there can exists dedicated identity server, STS. First, SPA communicates with other URI (token issuer) via oidc-client, then passed access token to the API.

So login page does not touch apollo, as there is no token yet. It shows transient screen, which launches browser redirect to STS with OpenID Connect / OAuth 2 process. When user is logged in at STS (like Google does), it redirects back to SPA (to the 'complete sign-in' page, specified in the STS configuration for that client).

In application workflow, there is action, known as 'silent refresh' where tokens are rotating in the background (within iframe with redirects to STS and back).

Apollo will be disconnected without token:

Navigated to https://localhost:8080/
[HMR] Waiting for update signal from WDS...
[Quasar] Running SPA.
Can access to '/': No.
Can access to '/sign-in': Yes. <-- Showing splash-screen before navigating to STS
[ApolloClient] Connecting...
[ApolloClient] Disconnected.
UserManager.signinRedirect: successful <-- Now received STS data to start navigation on it
[WDS] Hot Module Replacement enabled.
[WDS] Live Reloading enabled.
[ApolloClient] Reconnecting...
[ApolloClient] Disconnected.
Navigated to https://localhost:5001 <-- This where user was authenticated at STS
Navigated to https://localhost:8080/sign-in/complete <-- landing page after authentication
[HMR] Waiting for update signal from WDS...
[Quasar] Running SPA.
Can access to '/sign-in/complete': Yes.
[ApolloClient] Connecting...
[ApolloClient] Disconnected.
[WDS] Hot Module Replacement enabled.
[WDS] Live Reloading enabled.
[ApolloClient] Reconnecting...
[ApolloClient] Disconnected.
[ApolloClient] Reconnecting...
[ApolloClient] Disconnected.
[ApolloClient] Reconnecting...
[ApolloClient] Disconnected.
UserManager.signinRedirectCallback: successful, signed in sub:  xxxxxxxxx
UserManager.getUser: user loaded
Can access to '/': Yes.
DefaultLayout.vue CREATED DEFAULT
Index.vue CREATED INDEX
[ApolloClient] Reconnecting...
[ApolloClient] Reconnected. <-- This is where API allowed to connect Apollo.

After a time:

[IdentityManager] Renewing silently...
UserManager.signinSilent: successful, signed in sub:  xxxxxxxxx

[Arsync]

Found that we can set lazy: true to prevent auto-connection before any client action being allowed. SubscriptionClient parameters can be found at this description.

So original question is not about current 'apollo extension' repo, but how Quasar boot system works to exclude some steps from it.

[lukadriel7]

@smolinari Actually, you are right, I was using the connection in the wrong place of the boot file. @Arsync I don't understand what you mean

[Arsync]

I don't understand what you mean

This will manifest itself when you start using websockets and subscriptions. Apollo in my case agressivly tried to connect even on log-in screen. So I've looked for exactly same solution to disable boot files. But found just 'lazy' property:

// apollo-client-hooks
export function apolloClientBeforeCreate({ apolloClientConfigObj, app /*, router, store, ssrContext, urlPath, redirect */ })
{
    const subClient = new SubscriptionClient(
        process.env.API_GRAPHQL_WSS_URI,
        {
            lazy: true, // <-- this one to get connected on first API call
            reconnect: true,
            timeout: 30000,
            connectionParams: getConnectionParams(app.identity), // solution-specific function, nevermind
        }
    );

    const link = new WebSocketLink(subClient);

    apolloClientConfigObj.link = link;
}

[smolinari]

This question seems answered so closing.

Scott