Add support for AbortHandler

[landerss1]

With this PR, we will have support for AbortHandler, which will be responsible for sending a result and aborting the middleware processing. This is to address the current issue where the Content-Type of the error response is always text/plan.

[simongottschlag]

I like it overall. Would prefer to find a way that doesn't require us to use interface {} for the context.

[simongottschlag]

I usually never use else and do early returns instead.

[simongottschlag]

Is it possible to not use interface {} here?

[bittrance]

I note that ErrorHandler and AbortHandler are actually used only in the various web framework packages and I wonder if they shouldn't be removed and replaced by a mechanism that allows for framework-specific options? I'll try to PR a proposal in the coming days.

[bittrance]

After some offline discussion, me and @landerss1 came to the conclusion that the current error handler is not very useful and that it would better to be able to provide a "failure handler" which gets a structured representation of the auth failure and would be expected to provide a status code, relevant headers and a []byte body. The framework adaptors would be expected to call this handle and convert the result to an actual HTTP response. Possibly, it should also be able to decide whether middleware evaluation should be aborted or not. Something like this:

type Response struct {
    StatusCode uint,
    Headers map[string]string
    Body []byte
}

func MyFailureHandler(failure Failure) *Response { ... }

We think a "HTTP abstraction" interface is reasonable, since go-oidc-middleware seems to have no ambition to support anything non-HTTP and the basic HTTP structure seems unlikely to change anytime soon. @simongottschlag ?

[simongottschlag]

After some offline discussion, me and @landerss1 came to the conclusion that the current error handler is not very useful and that it would better to be able to provide a "failure handler" which gets a structured representation of the auth failure and would be expected to provide a status code, relevant headers and a []byte body. The framework adaptors would be expected to call this handle and convert the result to an actual HTTP response. Possibly, it should also be able to decide whether middleware evaluation should be aborted or not. Something like this:

type Response struct {

    StatusCode uint,

    Headers map[string]string

    Body []byte

}



func MyFailureHandler(failure Failure) *Response { ... }

We think a "HTTP abstraction" interface is reasonable, since go-oidc-middleware seems to have no ambition to support anything non-HTTP and the basic HTTP structure seems unlikely to change anytime soon. @simongottschlag ?

I'm quite fine with that, or at least I think so. If both of you think it's the way forward I listen to you! 😊

We do have this that isn't http, but maybe isn't affected?

https://github.com/XenitAB/go-oidc-middleware/blob/main/oidctoken/token.go

[bittrance]

@simongottschlag Re oidctoken #253

[bittrance]

Closing because alternative implementation in #252 merged.