Hi,
Option 1 (everything in n8n workflow and mess with SOAP payloads; hackish, maybe?)
Use n8n’s predefined microsoft oauth2 credentials. Use a HTTP request with the credentialsl but have it hit YOUR OWN host (check out my gist : https://gist.github.com/galois17/31fb40495f3c952eb110586471060fa6) to pull out the access token from the header:
(I stood up a server to handle a get request that just pulls out the access token and dumps it in a json response. It works as an echo server. Kind of hackish….)
The node that follows it can utilize the access_token. A follow up node could be another HTTP request where you craft the Soap payload that consists of the access_token and so on.
Would need a “soap hack” before a “soap call”.
Of course, you’re leaking the access token all over the place, but that’s an option.
In any case, you can now manually build the SOAP payload:
<s:Envelope xmlns:s=“schemas.xmlsoap.org” xmlns:i=“www.w3.org” xmlns:a=“schemas.microsoft.com” xmlns:b=“bingads.microsoft.com”>
<s:Header>
<b:DeveloperToken>YOUR_DEVELOPER_TOKEN</b:DeveloperToken>
<b:AuthenticationToken>YOUR_ACCESS_TOKEN</b:AuthenticationToken>
<b:CustomerId>YOUR_CUSTOMER_ID</b:b:CustomerId>
<b:AccountId>YOUR_ACCOUNT_ID</b:b:AccountId>
</s:Header>
<s:Body>
</s:Body>
Option 2 (my preference, more secure, no messing around with SOAP payload and exposing the access token all over the place)
Yes, what you got from Gemini is a scheme that will keep the automation going without manual/user intervention. As long as the refresh token is used within some period of time, it stays valid. What you need is an Authorization Code Flow for this, where the first time around you would use a browser (no n8n involved) to get an auth code that you could use to exchange for a refresh + access token. You can use a HTTP request node to do the exchange, but you will be passing the tokens around. i don’t know what security concerns you must address with your company, so this may be a problem. I wouldn’t even bother, just write a quick script.
Once you have the refresh+access token, you would then just be in this ****perpetual motion******** which allows for automation– i.e., if access token expires or about to expire, just use refresh token to get a new access token.
I would save the tokens in AWS SSM and retrieve it from there.
I would actually move code that interacts with bing ads to AWS lambda or Azure Functions, and avoid any manual tweaking of any soap stuff– just use the bing ads python module. The tokens (refresh + access) could be stored safely there. But that’s me…
From the python code node (bingads sdk), you would pull the tokens from AWS SSM and make whatever api calls you need to bing ads.
I would also add a scheme to the workflow to exchange refresh tokens if what’s been in use expires.
That’s the idea if I were to do this. I would avoid modifying any SOAP payload– it’s extremely brittle. Just rely on bingads sdk to do that stuff properly.
-
Get AUTH_CODE by accessing this from your browser (something like this…):<YOUR_CLIENT_ID>&response_type=code&redirect_uri=<YOUR_REDIRECR_URL>&scope=https://ads.microsoft.com/msads.manage%20offline_access
-
Exchange for refresh + access token. Write a small script to hit (check whether you want common or consumers) with post request including CLIENT_ID, CLIENT_SECRET, AUTH_CODE: https://login.microsoftonline.com/consumers/oauth2/v2.0/token
-
Bring the refresh + access token into the n8n workflow. You should never have to do the above again. The access token is short-lived as designed, so use refresh token to get access token. The refresh token has a longer life and you can always exchange for a new one.. I would prefer to not to leak the access and refresh tokens all over the place, so my preference would be to move the access/refresh token management and logic to aws lambda or azure functions.
Khem
