Authorization plugins

@matt, I am starting working on JWT plugin. Strictly speaking, JWT falls under “authorization” more than it is “authentication.” Have you considered adding “http.authorization.providers.jwt” modules? This way we get http.authorization.providers.

1 Like

I haven’t written any authorization modules yet – just a single authentication module (basicauth) so far!

Feel free to be the first to do so. Ideally, all the authorization and authentication modules can work together: i.e. hopefully it won’t matter which module is used for authentication - any authorization module can work along with it; and vice-versa.

(The separation between the two is why I didn’t call them “auth” modules, however – so as to not be ambiguous!)

Edit: @greenpau Do you want an invite to our dev Slack? You seem to be pretty active at developing these modules and if you want to chat with other developers in a tighter feedback loop for anything, you might find this helpful! Let me know if I should send an invite to your forum email.

Do you want an invite to our dev Slack? You seem to be pretty active at developing these modules and if you want to chat with other developers in a tighter feedback loop for anything, you might find this helpful! Let me know if I should send an invite to your forum email.

@matt, yes, sure! For now, I am learning the dynamics of the plugins. I love the configuration flow! :slight_smile: One specific thought is how easy it would be to “codegen” an entire server config from OpenAPI spec.

Hoo boy, I have no idea. Maybe @Mohammed90 or @francislavoie is more familiar with it!

nop not me :sweat_smile:

1 Like

Perhaps the CUE definition PR can help us here :slight_smile: Just now I’ve run the command cue def *.cue -p caddy -d Config --out openapi -o caddy-api.json and got this output. I have no knowledge of OpenAPI, so I can’t judge whether it’s good/useful or not.

1 Like

That’s cool!

But, I cringe a little, knowing that Caddy’s config structure is extensible so a static definition like that is always going to be incomplete or outdated.

There’s a way to tell CUE to keep a struct open (i.e. allow undefined fields) by adding ... at the bottom, but I haven’t worked into that yet. Once we know we have proper basic definition that works, we can relax the definitions. But this opens up the dreaded question “is this a misspelling of an existing field, or is it a new undefined field?” which CUE won’t be able to answer.

1 Like

@Mohammed90, it IS useful :slight_smile: Just need the other way around :slight_smile: i.e. provide OpenAPI spec for an application and it would generate caddy handlers :slight_smile: that’s what I thought when I first saw “new” config.

Oh okay. There’s nothing immediate which I know to work. CUE is supposedly able to import OpenAPI spec (um… just tried it and I get nil pointer dereference), converting it CUE definition, but I’m not sure if we can use that to bring about a Caddy handler out of it. Maaaaybe we can work it into some form of an adapter or something. But yeah… nothing immediate

1 Like