More Flexible AuthDefinition

[shzhng]

Motivation

We use DropWizard Auth, which is unsupported by default-auth or auth definitions for services.

ideally there should be someway to generate a service with such a method

@Path("/this/is/a/path")
@POST
SomeResponse getSomeSecret(@Auth UserPrincipal principal, SomeRequest request);

Proposal

make the header option more configurable, perhaps something like so:

default-auth:
  header:
    type: UserPrincipal
    markers:
      - Auth
    param-id: Authorization # the default

[iamdanfox]

@shzhng how would you want a typescript or python client to interact with an API that has a rich 'UserPrincipal' type?

default-auth:
  header:
    type: UserPrincipal
    markers:
      - Auth
    param-id: Authorization

[shzhng]

so i'd imagine on client side it wouldn't change from the current behavior, which is just setting the 'Authorization': 'Bearer {TOKEN}' header?

i guess the flexibility doesn't change semantics of the HTTP call, simply the backend deser'd representation

[uschi2000]

@shzhng , the conjure language primarily describes the wire format of RPC messages and as such is likely not the right place for the feature you desire. It would make more sense as a flag to the conjure-jaxrs generator, but I suspect that there are a few problems to work through, e.g., the difference between client-side and server-side code gen.

[shzhng]

@uschi2000 understood and agreed. I supposed, given that (i believe) i'm able to sorta hackily generate what i want by doing the following

getSomeSecret:
  http: GET /this/is/a/path
  args:
    principal:
      param-type: header
      param-id: Authorization
      type: UserPrincipal
      markers:
        - Auth

albeit in a really cumbersome manner on every single endpoint (and also generating the unnecessary @HeaderParam("Authorization") , that this might be something that's possible to define on the wire format

[uschi2000]

Ha, you're poking at two unfortunate holes / legacy concepts in the conjure language: imported/native types and markers. At the time we defined them we didn't quite have the clarity of mind to delineate wire format concerns from generator/implementation concerns appropriately.