There's an obscure case in the API code where api_key and mixins could leak into a method's arguments when they really never should. This PR fixes that case, and also un-reverts #1015 (which was blocked due to this).
I'm not sure how best to fix that, honestly - the comment on https://github.com/UniversityRadioYork/MyRadio/blob/master/src/PublicAPI/index.php#L59 refers to the case where "the request body is the param", and I'm not quite sure what that means. Perhaps we just accept this as a fact of life, although we may want to catch this error instead of spewing the MyRadio stack (though it's hard to do that without masking another type error from inside that function...).
There's an obscure case in the API code where api_key and mixins could leak into a method's arguments when they really never should. This PR fixes that case, and also un-reverts #1015 (which was blocked due to this).
This doesn't fix the general case though - try calling https://ury.org.uk/api-staging/v2/show/14066/credits?unexpected=gobbledygok - if a method that takes one parameter is called with one parameter, no validation is done to ensure that it's actually called with the expected parameter.
I'm not sure how best to fix that, honestly - the comment on https://github.com/UniversityRadioYork/MyRadio/blob/master/src/PublicAPI/index.php#L59 refers to the case where "the request body is the param", and I'm not quite sure what that means. Perhaps we just accept this as a fact of life, although we may want to catch this error instead of spewing the MyRadio stack (though it's hard to do that without masking another type error from inside that function...).
To test: go to https://ury.org.uk/api-staging/v2/show/14066/credits?api_key=insert_apikey_here.