Bug: The Set User Roles interface has no request method restriction about wolf HOT 5 CLOSED

@Hcreak

You indicate in the document that the request method of the /wolf/user-role/set interface is POST, but I test accidentally found that the PUT method can also be successful. Is this a bug?
This is a known problem, there is no strict verification of the http request method, POST and PUT mixed should not have any problems.
Even if the user's appID list does not have this application, the role binding of this application can still be added and it can take effect
This problem is currently controlled from the Console interface. The backend interface has not yet been validated for this. I'll find some time later to work on the corresponding checksum issue. Or do you have time to address this issue and submit a PR?

from wolf.

Oh my god, LOL ;-) Just now, I did the test again.
I found that there are no effective restrictions in many places (For example, use the add user interface to add non-existent applications to the appID list)
Maybe your intention is to rely on the console front end to control，But there are so many scenarios using API，It is not elegant enough not to restrict the backend.

This problem is currently controlled from the Console interface. The backend interface has not yet been validated for this. I'll find some time later to work on the corresponding checksum issue. Or do you have time to address this issue and submit a PR?

I think this task is huge, maybe you can try to modify one interface as an example, I will try to modify other interfaces according to this example

from wolf.

Okay, I'll add this to my TODO list and work on it as soon as possible.

from wolf.

#9 In this PR, I added request method verification to any interfaces. I don’t know Whether it meets your coding style. Please review

from wolf.

All the above issues have been fixed.
ba97310
bc497b0
91a6a3f

from wolf.