Mutations depending on result of other queries

[icaroponce]

Hello there,

In the app I'm working, we manage the authentication token via React-Query, and consume this query in other queries hooks so that we take advantage of the stale management provided by RQ, as we need to refresh the token periodically.

The custom hook for getting the token looks something like this:

export const useToken = () => {
  return useQuery(
    ['token'],
    () => loginUser({ ... }),
    {
      select: (data) => data.token,
      staleTime: 1000 * 60 * 60, // the token is only valid for 1 hour
    }
  );
};

An "authenticated" query would look like this:

export const useData = () => {
  const tokenQuery = useToken();
  return useQuery(
    ['data'],
    () => fetchData({ token: tokenQuery.data }),
    {
      enabled: tokenQuery.isSuccess
    }
  );
};

so we make this query dependent of the previous one, which stores a valid token in the cache, this way we are sure that before the useData is executed, useToken will provide us a valid token.

While working with mutations, we don't have the enabled option, so when consuming the token in a very similar way we do for nomal queries we could eventually get a stale token. I understand the idea that queries are more "declarative" and mutations "imperative", but I'm trying to find a reasonable way to achieve the same we can do with the enabled property in queries for mutations.
In case you have a suggestion or could link me to something I missed that might help us solve this problem, that would be very appreciated.

Thanks in advance.

[TkDodo]

Hm. I would argue that loginUser itself should be a mutation: https://twitter.com/TkDodo/status/1483157923572457476

While your dependent query might work, there is no guarantee that you get a new token after one hour. For example, if you have a successful token and the hour passes, the token query becomes stale. If you then mount useData, useToken will trigger a background refetch, but it will stay in success state and your data query will be immediately enabled, running with the outdated token.

Usually, a better approach is to:

• have login be a mutation
• take the response token and put it somewhere (localStorage, zustand, redux)
• in each queryFn / mutationFn, read the global token and send it

Personally, I think cookies are a better way to manage access tokens, because they are sent automatically. If they are secure, httpOnly and same-site, I don't see a reason not to use them. But its a different architecture (and you need to have browsers that support same-site cookies, otherwise you have to manage CSRF and that sucks)

[icaroponce]

Hey @TkDodo, thanks for the clarifications and insights. I look for another solution taking in consideration what you pointed here.

[mfpopa]

I second what @TkDodo about the login executed as a mutation. Any request that creates data or makes changes is a mutation. The login creates a session/token.

I disagree with posting local storage as a place to store the token. NEVER store auth tokens in local storage because you open yourself up to XSS (cross-site scripting) attacks. Cookies configured as secure, httpOnly and samesite lax (or strict) are the way to go. Although once you do this you have basically reinvented session cookies, which begs the question: why use JWT for authenticating web apps?

• http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
• http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

[raegen]

@mfpopa whatever gave you and the intense author of those blog posts the idea that you can't access cookies with javascript, in exactly the same way you can access localStorage.
You are looking for security in the wrong place. The whole idea around token based authentication is minimisation and control of exposure in the event of exposure. You can't truly ever hide/protect/prevent access to the point of contact (credentials). What you can do is to devalue having access to it.