I agree, I don't think it's possible to accurately tell base64 from some random string without input from the user.
Am Sa., 18. Apr. 2020 um 23:46 Uhr schrieb Rodric Rabbah <[email protected]>: > Actually my suggested decoding step doesn't work either. I don't think > there's a sound way to record the binary property without cooperation from > the clients. > > -r > > On Sat, Apr 18, 2020 at 4:38 PM Rodric Rabbah <[email protected]> wrote: > > > Hello OpenWhiskers. > > > > When an action is created or updated, the controller detects if the > "code" > > part of the HTTP Request is base64 encoded or a plain text string. The > > current heuristic for detecting if the code is base64 encoded is buggy. > It > > uses a regex match > > > > > ^([A-Za-z0-9+\/]{4})*([A-Za-z0-9+\/]{4}|[A-Za-z0-9+\/]{3}=|[A-Za-z0-9+\/]{2}==)$ > > > > which will match a 4-character string such as "abcd" or "true". This is > > outlined in an issue https://github.com/apache/openwhisk/issues/4884. > > > > We used to attempt to base64 decode the code string to determine if it > was > > base 64 encoded but this was replaced with the regex match. For the most > > part the heuristic is OK but this is not completely sound. > > > > I am soliciting feedback on the following schema change to the API. The > > `binary` property on of the exec field is currently not required and > > ignored by the controller. This forces the controller to always try to > > determine the value of this property. > > > > Instead, I'm suggesting we modify the schema to accept the binary > > property. If present it is used as is and it is the caller/client > > responsibility to set it accordingly. In the absence of this property in > > the HTTP request, for backward compatibility, augment the heuristic to > > perform the expensive decoding step as a last step in the confirmation > > process. > > > > For actions already in the database (previously created actions), the > > `binary` property is already set in the document in the db and can be > used > > as is, instead of recomputing the value. > > > > In essence this is a step toward moving the responsibility to the clients > > instead of the server. > > Thoughts? In the absence of input, I will open a PR to implement the > > change in this general direction. Thanks for reading this far. > > > > -r > > > > >
