oAuth 2 protocol, Microsoft Azure cloud services 1

[Steve Yu]

Fellow colleagues.

Does VFP have commands that is capable of reaching endpoints that's only accessible via oAuth 2 protocol based on Azure ?
There are sample codes in various languages except VFP in GitHub.
Just wonder if it's feasible with VFP code alone (one of our guys wrote a routine in C# and built a DLL, that can be called from within VFP, that can do the trick).
Is there a more elegant way ?

Help appreciated.

Steve Yu

 

[Scott24x7]

Hi Steve,
No, but you can use WinHTTP com object.
I use this to interface with OpenAI GPT-4o.
ChatGPT suggests this approach:

LOCAL oHTTP
oHTTP = CREATEOBJECT("WinHttp.WinHttpRequest.5.1")

* Obtain the OAuth token
oHTTP.Open("POST", "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token", .F.)
oHTTP.SetRequestHeader("Content-Type", "application/x-www-form-urlencoded")
oHTTP.Send("client_id=...&client_secret=...&grant_type=client_credentials")
lcTokenResponse = oHTTP.ResponseText

* Parse the access token from the response
lcToken = EXTRACTTOKEN(lcTokenResponse)  && You need to parse the JSON.

* Use the token in an API call
oHTTP.Open("GET", "https://api.example.com/data", .F.)
oHTTP.SetRequestHeader("Authorization", "Bearer " + lcToken)
oHTTP.Send()
lcApiResponse = oHTTP.ResponseText

You'll have to sort out the JSON return as well, and you'll need an API Key.

 

[Steve Yu]

Thanks for the tip, Scott.
One of the requirements of this project was base64 encoding; where does this fit into the process you described ?

Regards,

Steve Yu

 

[MathiasB]

I find convinient to just code my own com component in c#. Then use that in vfp.

 

[Steve Yu]

I find convinient to just code my own com component in c#. Then use that in vfp.

Yes, that's what we did so far.
But we have also been able to code in 'native' VFP most other integration projects in the past.
It is much easier to maintain.
Here I'm stumped on the use of private key, with base64 encoding, of certificate for oAuth 2 validation on Azure.

 

[Michele65]

For these operations i use Chilkat's controls... They make the connection very easy.

 

[Steve Yu]

For these operations i use Chilkat's controls... They make the connection very easy.

Can you provide an example ?

 

[Chris Miller]

To the last question: https://www.example-code.com/foxpro/default.asp
Also, Bill Anderson maintains a library to make easier use of Chilkat libraries in VFP. I personally think Chilkat provides everything you need, but it may be helpful anyway, to know Bill Andersons GitHub repository for ChilkatVFP: https://github.com/billand88/ChilkatVFP

But then, Scotts example is already making things clear. First things first:

1. For OAuth2 you need to get a token from the site to use in all your following requests
2. Then you provide that token in an authorization header, Scotts essential line covering oAuth2 for all requests after initially getting a token is that:

oHTTP.SetRequestHeader("Authorization", "Bearer " + lcToken)

No matter if you use WinHttp.WinHttpRequest.5.1, Msxml2.ServerXMLHTTP.6.0,, Chilkats or any other http rerquest class, the method names may vary slightly, but you set a http request header.

For base64, VFP has STRCONV(). that's a completely separate conversion issue.

Well, and once more first things first: The inital things you need to get the token are Azure "credentials" you can find or set up in your Azure account. A client ID, API key, clent secret, whatever. You have to fill the gaps in Scotts sample code, of course. If your .NET assembly has this all encapsulated and you have no hands on your (companies) Azure account, you can't recode that in VFP and better make use of that assembly. Nobody here and no library from a third party will know your Azure credntial API keys and secrects, of course.

And then, there's still enough more to implement with JSON or XML parsing, deserialization, processing in general, for which you'll find libraries on GitHub or from West Wind or Chilkat, too.

 

[Steve Yu]

To the last question: https://www.example-code.com/foxpro/default.asp
Also, Bill Anderson maintains a library to make easier use of Chilkat libraries in VFP. I personally think Chilkat provides everything you need, but it may be helpful anyway, to know Bill Andersons GitHub repository for ChilkatVFP: https://github.com/billand88/ChilkatVFP

But then, Scotts example is already making things clear. First things first:

1. For OAuth2 you need to get a token from the site to use in all your following requests
2. Then you provide that token in an authorization header, Scotts essential line covering oAuth2 for all requests after initially getting a token is that:

oHTTP.SetRequestHeader("Authorization", "Bearer " + lcToken)

No matter if you use WinHttp.WinHttpRequest.5.1, Msxml2.ServerXMLHTTP.6.0,, Chilkats or any other http rerquest class, the method names may vary slightly, but you set a http request header.

For base64, VFP has STRCONV(). that's a completely separate conversion issue.

Well, and once more first things first: The inital things you need to get the token are Azure "credentials" you can find or set up in your Azure account. A client ID, API key, clent secret, whatever. You have to fill the gaps in Scotts sample code, of course. If your .NET assembly has this all encapsulated and you have no hands on your (companies) Azure account, you can't recode that in VFP and better make use of that assembly. Nobody here and no library from a third party will know your Azure credntial API keys and secrects, of course.

And then, there's still enough more to implement with JSON or XML parsing, deserialization, processing in general, for which you'll find libraries on GitHub or from West Wind or Chilkat, too.

Great insight, Chris.
Have been using West Wind's class library for all our API integration projects (XML,JSON decoding included); but this one seems more complicated.

".. you have no hands on your (companies) Azure account .."

That may be the situation we have here. Instead of client secret (since we don't have control over the account, it'd be hard for our trading partner to provide the secret each time it is renewed), we are provided with a certificate from which we are suppose to generate a private key to include in the authentication process, along with provided tenant ID, client ID, scope, etc. The documentation says we can go the long way or use MSAL to simplify the process. I understand the flow of "get the authentication token , pass the token to API, decode ". But the devil is in the detail. In particular the part of "base64 encoding of certificate key' to pass the authentication step.

Steve Yu