Unless all of the data you are loading is completely public, your app has some sort of users, accounts and permissions systems. If different users have different permissions in your application, then you need a way to tell the server which user is associated with each request.
Apollo Client uses the ultra flexible Apollo Link that includes several options for authentication.
If your app is browser based and you are using cookies for login and session management with a backend, it is very easy to tell your network interface to send the cookie along with every request.
withCredentials is simply passed to the
HttpClient used by the
HttpLink when sending the query.
Note: the backend must also allow credentials from the requested origin. e.g. if using the popular 'cors' package from npm in node.js.
Another common way to identify yourself when using HTTP is to send along an authorization header. Apollo Links make creating middlewares that lets you modify requests before they are sent to the server. It's easy to add an
Authorization header to every HTTP request. In this example, we'll pull the login token from
localStorage every time a request is sent.
The server can use that header to authenticate the user and attach it to the GraphQL execution context, so resolvers can modify their behavior based on a user's role and permissions.
In the case that you need to a refresh a token, for example when using the adal.js library, you can use an observable wrapped in a promise to wait for a new token:
Since Apollo caches all of your query results, it's important to get rid of them when the login state changes.
The easiest way to ensure that the UI and store state reflects the current user's permissions is to call
Apollo.getClient().resetStore() after your login or logout process has completed. This will cause the store to be cleared and all active queries to be refetched.
Another option is to reload the page, which will have a similar effect.