Determine whether someone is allowed to use transactions

[m-mohr]

Is there a way to determine in a standardized way whether an authenticated users is allowed to use the transaction endpoints?

Currently, I can't determine whether someone has permission to edit and offer the Edit button (in a web UI) to anyone that is authenticated. So people start to edit and then only when I submit the information to the endpoint, I get an error. That's too late.

Some potential possibilities are:

• Add a transaction link to the item/collection only when the user has permission to edit this entity (or is this already the case)? (per entity)
• Send Authentication header to the /conformance endpoint and only return the transaction conformance class when the user has permission to use tranactions (global)
• Add a tranactions flag to the landing page? (global)
• Use the OPTIONS method somehow to determine permissions for endpoints? (per entity)
• ...?

This came up in STAC, but as we share the same transaction extension mechanics, I thought it might be a good idea to raise this issue here.

[pvretano]

Part 4 defines the use of the OPTIONS method for this purpose. If a user is logged in and has the proper access control the OPTIONS methods on an endpoint, say /collection/{collectionID}/items, will indicate which methods are available and if one or more of POST, PUT or DELETE are available then the user has "edit" privileges.

[m-mohr]

@pvretano Thanks. I'm wondering how this works together with the following document:
https://fetch.spec.whatwg.org/#cors-protocol-and-credentials

Note that even so, a CORS-preflight request never includes credentials.

and

A CORS-preflight request is a CORS request that checks to see if the CORS protocol is understood. It uses OPTIONS as method and includes the following header:

Would we send two OPTIONS request from a web app? One OPTIONS sent by the browser as pre-flight and one OPTIONS from the web app itself? Is there potentially an issue with it that there are two different purposes for the same endpoint?

[pvretano]

@m-mohr as long as the headers that satisfy the CORS preflight request and the headers that tell you which methods and media types are acceptable at the endpoint don't interfere then I think one OPTIONS request should handle it.