Path calculation is not intuitive when adding additional modules about kompendium HOT 10 CLOSED

The README looks good (in the sense that I think I could find the solution from the README alone now). I can anecdotally say that the oauth authentication method appears to be recognized in addition to jwt, but the resulting swagger page doesn't let me put in my JWT I get from OAuth.

from kompendium.

Adding Kompendium.pathCalculator = AuthPathCalculator() to the code appears to fix this issue. Is there a way to make this the default?

from kompendium.

Yes this is the intended approach, but you make a really great point that this is not particularly intuitive.

The problem here lies in the modularity... the core package really has no concept of the auth package.

I wonder if we can adjust the way the path calculator is instantiated to allow for default overrides. Because you're right, when someone does add the auth package, they are definitely going to want to include this path, and making the user do the leg work to add it is not very seamless.

Will think more on this 🙂 But if you want to dig in through the code and see if you can put together a way to tackle this I'd love to see it!

from kompendium.

At the very least, I need to add better documentation around this. Really sorry that there is nothing in the readme about this!

from kompendium.

It is interesting that you ran into this bug.. the developer that created the auth module seems to have anticipated this as the KompendiumAuth object has an init block

init {
  Kompendium.pathCalculator = AuthPathCalculator()
}

Regardless, my initial design is bad, because if we ever have any extra modules, it will not work to simply override with another. Definitely need to rethink this

from kompendium.

Would it make sense to use some sort of interface list to hold the extended selectors? The current design appears to only support one extension without writing a when that calls handleCustomSelectors for each module you want to add. The CorePathCalculator's handleCustomSelectors could iterate over a hypothetical customSelectors list (or potentially use .filter{ some method in the interface that returns true if you handle the selector}.first() or something similar if you only want one module to handle it). This could also allow for multiple modules to add info to a route.

from kompendium.

We are on a similar train of thought :) I am working on a potential solution, should have a PR out soon that I'll link here

from kompendium.

@LandryNorris put out this PR ^^^ in particular check out the README documentation, want to make sure it is clear :)

I still think this implementation is a bit convoluted (particularly the handler method), but I can't think of a way to simplify it at the moment. Ideally, for 99.9% of users it will just work, and they won't have to worry about it, and then for the rare case where someone needs to add a path handler, hopefully the documentation updates will make that easier to understand

from kompendium.

Ooh interesting! That sounds like a different bug, could you open up a new issue for that?

from kompendium.

Hmmm @LandryNorris I just ran a couple things in the playground, auth seems to work fine in swagger as far as I can tell.. did you make sure to set securitySchemes = setOf("yourAuthScheme") in the MethodInfo?

from kompendium.