checkPermissionsOnly requests should be using HTTP OPTIONS

[MattBlissett]

The HTTP OPTIONS request is used to determine what request methods (DELETE, PUT, POST etc) are available for a particular endpoint.

DELETE http://registry-api.gbif.org/dataset/a3f3981e-6a8f-4c22-b566-73d033b07be2?checkPermissionsOnly=true
PUT http://registry-api.gbif.org/dataset/a3f3981e-6a8f-4c22-b566-73d033b07be2?checkPermissionsOnly=true
POST http://registry-api.gbif.org/dataset/a3f3981e-6a8f-4c22-b566-73d033b07be2/crawl?checkPermissionsOnly=true

and so on is a strange way to implement these checks.

[marcos-lg]

It is used to know if a specific user has permissions to perform specific actions. It was requested by the UI to enable/disable certain buttons.

[MattBlissett]

But why not use the standard OPTIONS request?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/OPTIONS

[marcos-lg]

I guess it could be done with OPTIONS but would require some effort to adapt the authorization logic in the registry.

Is it causing any trouble?

[marcos-lg]

I'm actually looking at the code here and it relies on the spring security mechanism because not all the authorization logic is in the filters. So the way it is implemented it fakes real requests to trigger the spring security checks but then they are intercepted. I think OPTIONS requests are treated differently by Spring so they don't trigger that mechanism. It'd require investigation to see if it's possible. Also not sure if this is still within the scope of an OPTIONS request.