has anyone done work integrating w/ the Garmin API...
# cfml-general
r
has anyone done work integrating w/ the Garmin API? When doing the oAuth handshake I keep getting an error about the authentication header being incorrect, but their documentation is not great. I can get the first step completed where it returns the user's token, but I can't seem to supply it correctly for the 2nd part.
p
Any code to share?
r
it is basically using cfhttp to call : https://connectapi.garmin.com/oauth-service/oauth/access_token?oauth_consumer_key=xxxx-[…]lfja&oauth_version=1.0&oauth_signature=ljflaksfaksfdlaf%3D (values replaced to keep things secure). The response is {"errorMessage":"Unable to read oAuth header"} with a 400 status code.
p
Are you passing it as a
type="header"
cfhttpparam?
r
I think I tried that, but I can try again.
p
And is your oauth_signature in URLEncodedFormat?
r
good catch - I will check that too
p
and what is your code for generating that HMAC look like
r
This is the hmac function written by a previous dev that worked w/ the stravia oath.... <cffunction name = "HmacSHA1Encryption" returntype = "binary" access = "public" output = "false" hint = "This Function create MAC encryption by passing Signature Key and Signaturestring(Messsage)"> <cfargument name = "signatureKey" type = "string" required = "true" hint = "Accepts Signature Key"/> <cfargument name = "signatureString" type = "string" required="true" hint = "Accepts Signature String/Secrete Message"/> <cfscript> //Converting String to Binary Representation local.binaryMessage = charsetDecode(arguments.signatureString, "utf-8"); local.binaryKey = charsetDecode(arguments.signatureKey, "utf-8"); //Creating java objects for secret key : used to construct a SecretKey from a byte array local.secretKey = createObject("java","javax.crypto.spec.SecretKeySpec"); /*Creating java objects for Massage Auhentication Code (MAC) : check the integrity of information transmitted based on a secret key */ local.secretMac = createObject("java","javax.crypto.Mac"); //Initialize Secret Key with our binary Key created above using HMAC-SH1 ALGO local.secretKey = local.secretKey.init(local.binaryKey,"HmacSHA1"); //Get an instance of our MAC generator for the given hashing algorithm. local.secretMac = local.secretMac.getInstance(local.secretKey.getAlgorithm()); //Initialize the Mac with our secret key. local.secretMac.init(local.secretKey); //MAC Processing the given byte with our secret Message. local.secretMac.update(local.binaryMessage); //Calling this method to Finish the MAC operation return local.secretMac.doFinal(); </cfscript> </cffunction>
p
Ahh yea looks norm
r
I will re-run trying to clean up the URL format and the header param to see if it was just mis-coded.
I have worked w/ other oauth systems w/o this kind of headache and I just wonder if because I am jumping in on someone else's code I have gotten in the weeds. Thanks
p
Its based on oauth 1 which is bleh
r
yeah - wish lucee had a nice generic cfoauth tag that could be used for any oauth system reliably...
💯 1
b
Hey Reuben, just my two cents, but I would prefer that Lucee did not offer such a tag. From my point of view Lucee should be kept lean and mean (and open source). I could be wrong, but I think your issue is more related to an API that is poorly documented combined with possible legacy oAuth. Not easy I'm sure, but can be resolved.
r
well - more like an additional app, like the other features. I guess I could write one if I can carve out the time 😄
b
Gotcha, yeah like we all have plenty of extra time right? LOL