oauth / oauth2 authentication from tclcurl, curl, using HTTP POST with json

Clovertech Forums Cloverleaf oauth / oauth2 authentication from tclcurl, curl, using HTTP POST with json

  • Creator
    Topic
  • #115895
    Ken Smith
    Participant

      I have an interface requiring oauth authentication. I call the authentication service to identify myself and then am handed back a token, which I can then use in a following step to call an update service.

      I ran the following from the command line on my server to ensure curl is supported:

      curl –location –request POST ‘https://testserver/api/public/tokenauth/authenticate’ –header ‘Content-Type: application/json’ –data-raw ‘{“tenancyName”:”tenant”,”userNameOrEmailAddress”:”tenant@tenant.uk”,”password”:”PASSW0RD123″}’

      The result message for this call is returned, and the message includes the token as expected.

      I’m trying to do something similar with tclcurl in a tcl script.

      package require TclCurl
      echo “start oauth”
      echo “about to call authentication service”
      set url “https://stg-mdc-uks-public-api.azurewebsites.net/api/public/tokenauth/authenticate”
      set jsonBody “{\”tenancyName\”:\”tenant\”,\”userNameOrEmailAddress\”:\”tenanct@tenant.uk\”,\”password\”:\”PASSWORD\”}”
      set JSONResponse “”
      echo “url is $url”
      set typ “application/json”

      set ch [curl::init]

      $ch configure -post 1

      $ch configure -postfields $jsonBody

      $ch configure -url $url

      $ch configure -httpheader [ list “Content-Type: $typ”]

      $ch configure -bodyvar JSONResponse

      catch { $ch perform } returnCode

      echo “returncode is $returnCode”
      echo “message is $JSONResponse”

      When I run this from a thread and check the output, there are no errors. The value for returnCode is 1, but JSONResponse appears to be empty.

      Assuming that I am correct in thinking that the authentication service has been successfully called, how can I get the response message as it doesn’t seem to be returned, or maybe I’m looking for it in the wrong place.

    Viewing 3 reply threads
    • Author
      Replies
      • #115903
        Tipu Razaq
        Participant

          Try:
          catch { set output [$ch perform] } returnCode
          To get the HTTP response code, after the above has been executed, try:
          set httpResponseCode [$curlHandle getinfo responsecode]

          • This reply was modified 4 years, 9 months ago by Tipu Razaq.
        • #115907
          Ken Smith
          Participant

            While that works without error, I don’t get back the authentication token meant to be returned by the service. Browse output shows:

            [tcl :out :INFO/0: fetchToken:03/12/2020 10:24:16] returnCode: 1
            [tcl :out :INFO/0: fetchToken:03/12/2020 10:24:16] httpResponse: 0
            [tcl :out :INFO/0: fetchToken:03/12/2020 10:24:16] oauth return message is:

            I’m not seeing and perhaps not getting back the token, which will be a ridiculously long string of gibberish.

            The call from the command line returns a token of the nature “A1L2lkZW50aXR5L2NsYWltcy9uYW1laWRlbnRpZmllciI6” (that’s not the full token but you get the idea).

          • #115950
            Ken Smith
            Participant

              Update: I have finally got this to work, the issue, to my mind, was pretty arcane, but maybe I should have seen it coming. I copied code from various responses/issues described, which copied into my Cloverleaf with quotation marks of the type “”, e.g., “Content-Type: $typ”]

              However, I noticed, finally, in the script editor that quotation marks of “” were clearly preferred. I changed all of the quotation marks to “” from  “” , e.g. “Content-Type: $typ”, and the script executed properly.

              Quotation marks, who knew? Well, probably I should have…

            • #116135
              Ken Smith
              Participant

                Just to round this off, I then had to pass the oauth / bearer token to the next endpoint, in this case an endpoint that used data in the message to update the database. I had to do this in fact for two different projects and the configuration was slightly different in each case. In both cases, I first extracted the token from the response message and stored it in a variable called “token”.

                The basic approach is to set an authorization header and provide the token as the value, accounting for other headers also required, e.g.:

                $ch configure -httpheader [ list “Content-Type: application/json” “Authorization: $token”]

                (in this case, $ch is the handle to a curl session – see above responses/comments)

                One site required the header to be interpreted as “Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9”

                The other site required the header to be interpreted as:

                “Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9”

                So you’ll have to take the specifics of endpoint into account and set the token accordingly.

                For me, the most obvious way to make this all is to put the call to the authorization endpoint and the call to any subsequent endpoint in a single tclscript. First you get the token, then you call an endpoint with the token. I’m sure those who have more experience with this have sounder methods, but this being the first time I’ve had to do things this way…

                I found a related thread that recommended calling the tcl in the routing from Thread A to Thread B. This works for me. As the message is being logged along the way, and the tcl script is doing the sending, I am using a simple file thread for the destination. I have left the file settings blank, default behaviour with no output file defined is to simply throw the message away. However, you could try setting a file destination if you still want to log or archive the message.

                Those who’ve done this more than me – this is the first set of projects where I’ve had to take this route – will no doubt have better ideas.

                 

            Viewing 3 reply threads
            • You must be logged in to reply to this topic.