Allow path parameters to be specified as security inputs (Tapir)

[smosca-ct]

Sometimes, the security logic of an endpoint needs to get access to path parameters. For example, the product search endpoint (/:projectKey/products/search) security logic checks that the API token provided by the client actually has the permission to read products off the :projectKey path parameter.

Currently, this kind of checks can't be implemented cleanly by using code generated by this generator, because path parameters expressed as both security inputs and normal inputs don't care about each other. For example, this endpoint definition (for the product search endpoint described above):

endpoint
  .post
  .in(path[String]("projectKey") / "products" / "search")
  .securityIn(path[String]("projectKey"))

Actually matches /:projectKey/:projectKey/products/search.

To work around this problem, we currently employ extractFromRequest, but we consider this solution pretty much an hack.

To properly support this use case, we could instead:

1. Either leverage a setting in the build definition, which flags a path parameter as a security input for certain endpoints. Something along the lines of scramlSecurityInputs = Map("/:projectKey/products/search" -> "projectKey"), or
2. Parse the security scopes of an endpoint, and include the matching path parameters as security inputs instead (when present)

[osxhacker]

Hi @smosca-ct ,

As you have identified, Tapir's path method interacts with URI segments much like an IterableOnce. The implementation of securityIn supports this conceptual model:

def securityIn[B, AB](i: EndpointInput[B])(implicit concat: ParamConcat.Aux[A, B, AB]): EndpointType[AB, I, E, O, R] =
    withSecurityInput(securityInput.and(i))

Hence the "double projectKey" matching you documented when securityIn is used with the path method. Where the challenge lies in introducing path-based security tokens is that the specification of supported RAML Security Scheme Types does not define support for path-based tokens. There is a supported security scheme named "Pass Through" which is close to the scenario you describe, but notably does not include path segments:

Headers or query parameters are passed through to the API based on a defined mapping.

To my knowledge, the projectKey concept referenced in the project tests does not refer to a security key/token.

HTH