I need to manipulate response data in a middleware function. Assume I have product handlers and customer handlers. Product handler returns a list of products and customer returns a list of customers. In the middleware function, I want to convert these responses into ApiResponse struct.
type ApiResponse struct{
Data interface{}
Status ApiStatus{}
}
func someMiddleware(c *gin.Context){
//before handlers
c.Next()
//I need to access response and manipulate it
// apiResponse := ApiResponse{}
// apiResponse.Data = returnedData
// apiResponse.Status = ApiStatus{}
}
I don't want to fill ApiResponse in all handlerFunctions.
Probably a bit too late, but anyway.
The easiest way is usually to use Get and Set methods of gin.Context to pass data between your middleware and your handlers.
But if you really need to intercept responses, see my answer about logging response in gin. The only difference is what you do with intercepted response, but everything said there about intercepting it stays true.
Related
I want to use the same handler for multiple endpoints in a Go Gin app:
router.POST("/box/:boxID", controllers.AddUpdateBox)
router.PUT("/box/:boxID", controllers.AddUpdateBox)
router.PATCH("/box/:boxID", controllers.AddUpdateBox)
In the controller I want to find what is the request method (POST, PUT or PATCH).
func AddUpdateBox(c *gin.Context) {
}
How do I get the request method from the Gin context?
c.Request.Method
This member represents the method of the request
c.Request.Method
Struct http.Request on Package net/http has a property called Method that can be used to check the method on a currently running request.
I am looking to get the req object in the cypress route method. By doing so I could decide what the user gets back when hitting the graphql route which has dynamic responses. Has anyone be able to accomplished this?
I think having access to this would be incredibly useful.
I hope this helps, where xhr.requestBody does help in accessing the request body,
cy.route("GET", "/login").as("getLogin");
cy.get("#contactID").type("email#gmail.com");
cy.contains("Login").click();
cy.wait("#getLogin").then(function(xhr) {
// we can now access the low level xhr
// that contains the request body,
// response body, status, etc
const request = xhr.requestBody;
expect(response[0]).to.have.property("SomeKey", "Data");
const response = xhr.responseBody;
expect(response[0]).to.have.property("LineName", "Line A");
});
I am using a custom logging handler in my Go web server like this:
func main() {
// ... Set up everything
router = mux.NewRouter()
router.Handle("/apilookup",
raven.Recoverer(
jwtMiddleware.Handler(
http.HandlerFunc(
doApiLookup)))).Methods("GET")
loggedRouter := handlers.CustomLoggingHandler(os.Stdout, router, writeLog)
http.ListenAndServe(listenAddr, loggedRouter)
}
In the writeLog function, I have made my own version of the Gorilla handlers.LoggingHandler, which logs a lot of additional information.
One thing I would like to do is log the user for authenticated requests. Users authenticate to this server using JWT (using the Authorization: Bearer ... header). I am using Auth0's go-jwt-middleware to parse the token and set its value in the Request's context.
I tried to log the user's email address (one of the claims in the JWT) like this, based on the middleware's documentation:
func writeLog(writer io.Writer, params handlers.LogFormatterParams) {
// ... SNIP
// If we can't identify the user
username := "-"
if userJwt := params.Request.Context().Value("user"); userJwt != nil {
claims := userJwt.(*jwt.Token).Claims.(*jwtClaims)
username = claims.Email
}
// ... SNIP
}
The problem is that username is always the initial value - and not the expected value from the JWT.
By adding log.Printf("%+v\n", params.Request.Context()) above the if, I see that the context doesn't actually contain the parsed JWT data here.
As far as I can tell, the reason this is not working is because the middleware creates a new Request with the updated context, so only middleware further down the chain can see it. Because the logging middleware is above the JWT middleware, it does not have that same context.
I know that I can re-parse the JWT in the logging handler (because I do have access to all the headers), but that seems like a lot of overhead for logging.
Is there a better way to do this that will allow me to have access to this data where I want it?
I have an issue to implement middleware i want to use negroni.Wrap function for validate user location and one for calling handler below is my route:
r.Handle("/users/{userID}", negroni.New(
negroni.HandlerFunc(validateTokenMiddleware),
negroni.Wrap(&userLocation),
negroni.Wrap(&userDetailHandler),
)).Methods("GET")
and &userLocation is object of an struct which contain db information, here when i request for handler then that time both wrap execute together. But i want execute &userlocation first and if any errors occur so next wrap should not be execute , how to resolve this issue.
Thanks.
Use a middleware having ServeHttp Method which will be called using userDetailHandler as receiver inside middleware. And pass your db struct in middleware as an argument . You should use single wrap.
r.Handle("/users/{userID}", negroni.New(
negroni.HandlerFunc(validateTokenMiddleware),
negroni.Wrap(userDetailHandler.Middleware(&userLocation)),
)).Methods("GET")
func (userDetailHandler *UserDetailHandler)Middleware(res http.ResponseWriter, req *http.Request, userLocation *userLocation){
// use your serve Http inside this
userDetailHandler.ServeHttp(res, req)
}
I'm using gorilla/context in a web app. The example in the docs looks like:
func MyHandler(w http.ResponseWriter, r *http.Request) {
//...
val := context.Get(r, foo.MyKey)
//...
}
How can I unit test a handler that works like this? The only way I've managed so far is to use the context package inside my tests. I'm thinking at the moment that I could inject a context parameter into the handler but then I'm not conforming to the HandlerFunc interface.
This is a classic cross-cutting concerns example.
You are using a 3rd party to magically handle input params for your unit under test. By that very definition, you are going to have to do some extra setup to prep the context for the state you want.
When it comes to Go http handlers (which the convention is to KISS it), you shouldn't need to "reach out of context" of your func to get extra data: keep all the data you need within your single func.
Personally, I try to avoid corrupting my handlers like this. I think I've only used gorilla's context once out of the dozens of big sites I've built. And that was basically to get around a cached response, just to keep the data refesh to the end user. Of which I simply ignored in my unit tests, as it was out-of-scrope of what I was testing.
Instead, I use middle-ware wrappers to setup the basics I want in my handles and modify the handler's signature accordingly.
caching
logging
authentication and authorization
json marshaling
context (e.g. expected User{} object loaded from DB)
...etc. I would create a middle-ware that wraps your handler when you register it with mux that uses gorilla/context to lookup your cookie or userid or something, hidrates that user object from cache, DB, redis, etc, and then calls your handler that would have a signature like:
func MyHandler(u User, p Page, w http.ResponseWriter, r *http.Request) {
// u is the User object loaded from middle-ware
// p is your global Page object... etc
}
That way, your unit tests inject only the items you need under test.
And you can integration test your middle-ware on a QA server with expected User and Page objects in a datastore.
The way my team does it is to add a name to the route handler and then in the tests we call that route by name.
This is how to add a route:
r.HandleFunc("/<route>", MyHandler).Methods("GET").Name("MyHandlerByName")
Then this is how to test it
r.Get("MyHandlerByName")
One way to test handles is modify the way in which they are created. for example, Creating a function that return a http.HandlerFunc, this function can have parameters. You can mock the values that you send to the function
Without parameters
func State() http.HandlerFunc {
return http.HandlerFunc(func(pResponse http.ResponseWriter, r *http.Request) {
// your code
})
}
With Parameters
func State(pParam1,pParam2,pParam3 ...) http.HandlerFunc {
return http.HandlerFunc(func(pResponse http.ResponseWriter, r *http.Request) {
// your code using pParam1,pParam2,pParam3
})
}
The mapping will be
http.HandleFunc("/State", State())
or
http.HandleFunc("/State", State(value1,value2,value3 ....))