Add custom HTTP handler for authentication errors

[cyb3r4nt]

This patch gives a possibility to configure custom HTTP handlers, which can change the default authentication error responses in the middlewares.

The default implementation uses http.Error() method, which produces content type text/plain
and simple textual messages rendered directly into the response body.
In some applications this behavior may not be enough,
and there may be a need to produce different responses like JSON or HTML.
The AuthErrorHTTPHandler interface allows to intercept authentication errors and write HTTP responses according to specific application requirements.

I also added some additional middleware methods, which allow to configure different AuthErrorHTTPHandler implementations for different HTTP routes. Some routes in the applications may require different response bodies or attributes.

[coveralls]

Pull Request Test Coverage Report for Build 10662414915

Details

• 43 of 45 (95.56%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.08%) to 83.519%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
v2/middleware/auth.go	38	40	95.0%

Totals
Change from base Build 10642899118:	0.08%
Covered Lines:	2630
Relevant Lines:	3149

---

💛 - Coveralls

[paskal]

Overall looks good, just two minor nitpicks.

[umputun]

"In some applications, this behavior may not be enough, and there may be a need to produce different responses like JSON or HTML."

I don't really get it. What are those cases that need a custom body in response, in addition to the status code? So far, I have seen one semi-convincing case where UI code expected some JSON body in all responses, including 401/403, because it had some trouble handling content-type. To me, it is not a good reason for the change, but in case you have some valid use cases in mind, please share.

[cyb3r4nt]

I am trying to create an application where server side page rendering is used (go html/template, templ or any other template engine).
If some protected page is opened in the browser without required authentication or authorization,
then i want to display a proper error page to the user,
and pick some template based on the auth outcome.
It is a simple exchange of the HTML documents without any AJAX support in the client.

This scenario is possible because there is an HttpOnly JWT cookie,
which is sent by browser in HTTP requests.

Right now it is not possible to output a custom response to user
because auth middleware works before any application logic,
and auth middleware writes its own HTTP response to the http.ResponseWriter.

It may be possible to wrap auth middleware and pass a fake http.ResponseWriter to the underlying logic,
including auth middleware itself,
and then decide what to do after wrapped middleware chain completes,
but such use case will require unnecessary copying for valid and authenticated requests,
which count is usually greater than count of auth failures.

In addition, i want to replace the logger.L with my own logger with structured logging and tracing support.

Such proposed AuthErrorHTTPHandler allows to control what is written to HTTP response,
and execute some application specific logic when authentication/authorization has failed.

This is what i want to achieve by introducing this change.

[umputun]

Right now it is not possible to output a custom response to user because auth middleware works before any application logic, and auth middleware writes its own HTTP response to the http.ResponseWriter.

I don't get this part. There is nothing in the auth middleware forcing you to put it first in the chain of middlewares. You can have others, like logging, panic/recovery, and the custom 4xx status code handling before the auth middleware in your chain.

Unless I'm missing something, I think you can just add your own middleware prior to the auth middleware in your chain and implement your own handling of status codes with a custom implementation of the ResponseWriter. I don't see why it would need to care about the underlying auth middleware, as all you do here is inspect the status code set by auth (or any other middleware in the chain it is wrapping).

Generally speaking, to me, the auth library seems to be the wrong place to provide rendering-related customizations.