I need to send a URL from FileMaker to a webapp but I want to include an encrypted "auth" url parameter.
Since the receiving REST app needs to be able to decrypt the encrypted string sent, I would need to know what encryption method FileMaker is using.
Suggestions on how to send secure "auth" strings in URL params?
EDIT: see my next reply first.
It's hard to say what the best solution is, but you'll wanna either:
- Use an asymmetric key and give the public key to FileMaker and the private key to the web service.
- Or a shared secret where both systems use the same key.
As for encrypting and decrypting the data, that's not the most straightforward. I'd say maybe look at using a webviewer or NodeJS service to do the encryption in the filemaker file and then use the same/similar approach in the web service to decrypt using the same key.
Otherwise, if you want to use FM's built in
CryptEncrypt fn, it might be possible, but I haven't hammered away on the actual implementation to know how to decode something in JS that was encrypted with
CryptEncrypt in FM. I also vaguely recall hearing that it might not be a viable approach. So look at using a service/webviewer.
Actually I wanna followup on one more thing. Do you actually need to manually encrypt the value when sending to your webservice?
Can you instead POST the data from FM, making sure you have SSL to encrypt the traffic in transit? Then put your secret in the POST body instead of the url?
try this as one of the option to pass in the InsertFromURL script step:
-H "Authorization: Basic "& Base64EncodeRFC ( 4648 ; YourUserAccountName & ":" & YourLoginPassword ) & "\"
or instead of 4648 try 3548
somehow it didn't paste it correctly: the last 2 char of the header I added should be backslash:
Edit: fixed it with double backslash ..
All great replies, thanks all!
I ended up just creating a random UUID that will be passed to the service. On the service side, I compare it with a multi-hundred-time hashed value of that UUID to validate.
Spring offers "formal" shared secret implementations, but I opted not to go that route since the URL called by the webhook is SSL encrypted anyway.