access token expired scenarios using rest client

[avivek]

Does TS force have the ability to refresh an expired access token by itself.
Current behaviour of setting the RestClient at the time of object creation, would create problem when the access token expires during the usage of this object for further operations.

Is there a suggested method of handling this?

[ChuckJonas]

Unfortunately it's not yet been implemented..

My use case has always been on-org (using the session_id). Refresh token functionality would not be too hard to add though.

To make this work, we would need to make the following updates:

• add a handler that when the request fails due to an expired token, it checks if there is a refresh_token on the config. if there is:
  • make the refresh request to acquire a new token
  • replay the last request

We've discussed completely moving away from the ORM style object which would also address this, but have no timeline in which we would get around to that.

[avivek]

Thanks a lot for the update.

[ChuckJonas]

I started working on a solution. It should actually be pretty easy using the axios Interceptors .

It could be hacked together by just checking for a refresh token on the default auth, but a better solution would be to build support for more comprehensive oAuth strategies.

[avivek]

Thats good to know.
Would it be possible to not tie the solution to only using refresh tokens.
Rather have the ability to also take in a handler function, which could be called if any time the token expires. This could be actually more generic then tying into refresh token based implementation. The Handler function can return a promise, that should resolve to the current config object, or if it fails that might indicate the failure to get token.
Per my understanding, when we use the Username, Password flow in salesforce, refresh token is not given.

[ChuckJonas]

that might be a more flexible solution... I was planning on implementing the Username & Password "refresh" and refresh flows as build in "Auth" handlers. It might be easy to provide built in support for the common authentication methods but also allow overridding

[wuservices]

@ChuckJonas I noticed you mentioned:

My use case has always been on-org (using the session_id)

and the docs on auth seem to only reference a username-password flow in the context of OAuth.

Does that mean that right now, ts-force isn't designed to handle getting tokens for a user-initiated OAuth flow, like the browser-based OAuth flow in JSforce?

[ChuckJonas]

@wuservices that's correct. oAuth2 flows are fairly trivial to setup, so it could be added easily... An equivalent example would look like this:

const getOAuthUrl = (scopes: string) => {
  const clientId = process.env.CLIENT_ID;
  const redirectUrl = `${process.env.SITE_URL}/oauth2/token`;
  return `${process.env.INSTANCE_URL}/services/oauth2/authorize?client_id=${encodeURI(clientId)}&redirect_uri=${encodeURI(
    redirectUrl,
  )}&response_type=code&prompt=login&scope=${encodeURI(scopes)}`;
};

// you could just redirect them directly from the browser... Don't really need an endpoint for this.
app.get('/oauth2/auth', function(req, res) {
  res.redirect(getOAuthUrl( 'api id web' ));
});

// typically you would store the auth token in a user-session (jwt)
app.get('/oauth2/token', function(req, res) {
 const params = {
        grant_type: 'authorization_code',
        code: code as string,
        client_id: process.env.CLIENT_ID,
        client_secret: process.env.CLIENT_SECRET,
        redirect_uri: `${process.env.SITE_URL}/api/token`,
      };
 const searchParams = toFormData(params);

 const response = await fetch(`${instanceUrl}/services/oauth2/token`, {
        method: 'POST',
        headers: {
          'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8',
        },
        body: searchParams,
  });

 if (response.ok) {
         const respJson = await response.json();
         const { access_token: accessToken, id, instance_url: instanceUrl } = respJson;
         const tsForceClient = new Rest({
             accessToken, instanceUrl
         });
         // do stuff
         const describe = tsForceClient.getDescribe('account');
  }
});

Typically this type of thing would be handled by the authentication middle wear (passport, next-auth,etc) and you'd want to store the token in a session cookie or JWT...

I have been working on getting refresh tokens to automatically regrant auth tokens (it's done, but I need to do more QA)... I guess I could add some small utilities to make it easier to work with oAuth flows (or maybe just a separate library).

[ChuckJonas]

@avivek you may have moved on and don't care anymore, but I wanted to provide an update to this:

Would it be possible to not tie the solution to only using refresh tokens.
Rather have the ability to also take in a handler function, which could be called if any time the token expires. This could be actually more generic then tying into refresh token based implementation. The Handler function can return a promise, that should resolve to the current config object, or if it fails that might indicate the failure to get token.
Per my understanding, when we use the Username, Password flow in salesforce, refresh token is not given.

You can actually already do this, via the axios instance, which is exposed on any client:

import {Rest} from 'ts-force';
const client = new Rest();

//"request" is an AxiosInstance
rest.request.defaults.adapter = myCustomAxiosAdapter;

Axios already has a ton of powerful stuff around adapters (unfortunately not well documented) and interceptors, but I do want to create an interceptor to automatically generate new auth_tokens on expiration.

Here's an example of how you can add a custom retry hook:

import * as rax from 'retry-axios';

const client = new Rest();

client.request.defaults['raxConfig'] = retryHandler;
client.request.defaults['raxConfig']['instance'] = client.request;
rax.attach(client.request);

const retryHandler = {
  retry: 7,
  retryDelay: 200,
  shouldRetry: (err: AxiosError) => {
    const cfg = rax.getConfig(err) as any;
    if (cfg.currentRetryAttempt < cfg.retry) {
      return !err.response;
    }
    return false;
  },
  onRetryAttempt: (err) => {
    const cfg = rax.getConfig(err) as any;
    console.log(`Retry attempt #${cfg.currentRetryAttempt} : ${new Date().getTime()}`);
  },
};

[wuservices]

@ChuckJonas wow thank you for taking the time to cook up an example. I think that sounds pretty viable. Right now, I'm just trying to get a Zendesk app bootstrapped with Vue and TypeScript, but once I start pulling in data, I can't wait to try this out.

Also, I just happened to see your BASS today and loved it. Sent you a tweet as to not derail this issue too much.

[ChuckJonas]

@wuservices I went ahead and added this code via a couple utility functions. You need to use 3.0.0-rc.22 (I'm about to release, so if you are starting a new project, you want v3 anyways).

See the updated docs.

[wuservices]

@ChuckJonas glad you pointed out v3. I'll take a look at that and the new utilities. I'm trying to build a static browser app without a backend. Would I need the User-Agent flow vs the Web-Server flow?

[ChuckJonas]

@wuservices possibly...

I can add the user-agent flow... It's basically JUST redirecting the user via the authorization and then access token is returned in the redirect url. Your client code can then parse it from the URL.

Is this app only going to be used by a single, specific salesforce organization?

If you're trying to write a generic app that can make requests against any org, CORS will need to be added in each Salesforce ORG for your domain so it can make requests against the rest API.

In that case, you really just want a backend to make the request (you mentioned vue, so maybe checkout nuxtjs)

[wuservices]

@ChuckJonas Yeah the flow looks pretty simple, but it'd definitely be a nice addition to have the library help out. The app will run in an iframe in the Zendesk apps sidebar. Since it's internal only, it's just for a single organization. I think we can get a lot done from just the frontend, so not using a backend at all and using the User-Agent flow should keep things simpler.

Nuxt would definitely be an option if we needed to add a backend later, or we also love Cloudflare Workers.

[ChuckJonas]

👍 sounds like a good use. I will push a version today that should "support" the user-agent flow (it's really just updating a type).

The API for this will likely evolve slightly before v3 is officially released as to make it more streamlined, but not significantly.

[ChuckJonas]

@wuservices types for this should setup in @3.0.0-rc.23... I haven't actually tested, so LMK if it doesn't work.

Docs are here: https://app.gitbook.com/@cjonas/s/ts-force/v/3.0/guides/connecting-with-salesforce/oauth/user-agent-flow

Also added docs for the original issue: https://app.gitbook.com/@cjonas/s/ts-force/v/3.0/guides/connecting-with-salesforce/re-auth-on-token-expiration

Closing this out