Supporting /v2/token Auth Url
ahome-tm opened this issue · comments
Introduction:
Hello! I am just starting out with integrating with SFMC for my company and I am trying to use this SDK along with FuelSDK-Node-REST. At the start I am just trying to understand the best ways I can use these SDKs.
Task:
Easily Initialize this class for use. At the moment I feel like I'm really doing some wonky things to be able to make this Class work how I need it to. I think the root of my issues come from this class seems to be set up to work with the /v1/requestToken
route for authentication, but I do not have a legacy package as such I need to be able to use /v2/token
and the syntax between these to varies. Through a lot of digging into how the code works and lots of trial an error I can use the /v2
route.
My usage:
To just have a simple initialization process this how I get getAccessToken
to work.
// Simple Initialization
const options = {
clientId: myClientId,
clientSecret: myClientSecret,
authUrl: authUrl // https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
}
const AuthClient = new FuelAuth(options)
const authOptions = {
force: true,
json: {
grant_type: 'client_credentials',
client_id: myClientId,
client_secret: myClientSecret
}
}
AuthRest.getAccessToken(authOptions)
.then(resp => {
// I can see a valid response and my access token is under access_token
})
.catch(err => {
// handle error
})
If I wanted to make sure not to pass any options to getAccessToken
, then this is what I did to get it to work.
// Complicated Initialization
const options = {
clientId: myClientId,
clientSecret: myClientSecret,
authUrl: authUrl, // https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
globalReqOptions: {
json: {
grant_type: 'client_credentials',
client_id: myClientId,
client_secret: myClientSecret
}
}
const AuthClient = new FuelAuth(options)
AuthRest.getAccessToken()
.then(resp => {
// I can see a valid response and my access token is under access_token
})
.catch(err => {
// handle error
})
The Observation:
The module needs to be updated to be able to fluidly use both routes without much change to the client using this already. I think by changing the format of options
in the constructor or even how the request calls are made will help make this more user friendly. I also think it should give a standard response to whoever is asking for the token. (I have some understanding how the base class is working, so I am also trying to think of the best way to achieve this.)
Takeaway:
The way things are now really do not allow for me to use FuelSDK-Node-Rest
fluidly as I would like. The fact that FuelSDK-Node-Rest
makes assumptions on the format of the response is where I am getting blocked. I cannot make any calls using the REST module since I get a Error: No access token
which is happening because of how that code is looking for the access token. It expects accessToken
and since v2
returns access_token
that check for the token fails.
Hoping to get more insight on this!
Regards
It expects accessToken and since v2 returns access_token that check for the token fails.
I've seen this too. And this seems like a pretty straightforward thing to fix.