AnsweredAssumed Answered

FM DataAPI decoding of base64 not same as FMPA fn?

Question asked by wfgclapp on Aug 22, 2018
Latest reply on Aug 23, 2018 by bigtom

FMS 17.0.2.203

 

Please reference screenshot at bottom for example strings.

I get a 212 (invalid user/pass) error when attempting to acquire a session token from the FM Data API, using string B as the "Authorization: Basic" header. I am making my request from a linux based host system.

 

If I make my request explicitly stating the creds with '-u <user>:<pass>' as opposed to the '-H Authorization: Basic <encodedString>' header, I get my token back fine. This tells me my request is structured correctly and I have all my FMS and file settings right.

 

If I copy and paste my system's encoded string (B) into FMPA17 Data Viewer and use FileMaker's Base64Decode function, I get my correct <user:pass> string that I am trying to get my token with. But the Data API obviously does not yield the same result. Is this a bug? My system encodes with the standard: 3548

 

Notice in screenshot that, for the same input, FMPA17 results in a different encoded string (A) than my system (B), even though FMPA evaluates MY encoded string (B) to the same value that yields (A) for FMPA17. I claim my https request is structured correctly and all FMS and file settings are correct because I can copy/past string (A) generated by FMPA17 into my request and I get back my token successfully.

 

In summary:   My system and FMPA17 generate different encoded strings for the same input. I guess that makes sense if the RFC standards used in the encodings are different.   But why does the FM Data API not accept my system's encoding when FMPA17's Base64Decode function decodes my system's encoding just fine?

 

 

 

Outcomes