pacedotdev / oto

Go driven rpc code generation tool for right now.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Handling Cookies / Status Codes / any other HTTP related headers

fr3fou opened this issue · comments

commented

How would one drop down to the http.Request or http.Response structs from inside service implementations (as shown below) - for purposes such as accessing r.Header / r.AddCookie() / w.WriteHeader(400) etc?

oto/example/main.go

Lines 17 to 22 in df5a36e

func (greeterService) Greet(ctx context.Context, r GreetRequest) (*GreetResponse, error) {
resp := &GreetResponse{
Greeting: fmt.Sprintf("Hello, %s.", r.Name),
}
return resp, nil
}

By design you don't have access to any http related methods because are related to the transport layer, and oto design is independent of the transport

commented

That's what I noticed too. What would you guys do if you had to achieve that?

You can change the server template code to pass in the request object and the response writer if you want access to it.

But @fr3fou, could you take a minute to explain your use case please?

commented

But @fr3fou, could you take a minute to explain your use case please?

Implementing auth endpoints for a backend! Login / Register / Checking if session exists etc. Can this tool be used for auth-related endpoints or should it be used strictly for everything else?

I found this thread while looking into how to work with custom errors.

To make oto work for my use case, I would need at least some of the 4XX HTTP client errors:

  • 400 Bad Request: invalid inputs, message field validation
  • 401 Unauthorized: for failed login requests (could live without it since authentication is always a special case)
  • 403 Forbidden: missing permissions
  • 404 Not Found: search requests, requesting stuff that doesn't exist anymore

Should be easy to implement this with sentinel errors.

@iwittkau You can modify the client template to capture and preserve this information. This is the recommended approach for Oto, users copy and modify the templates to solve their own problems. Hope this helps?

@matryer thanks! I just realized that the oto server's OnErr is an exported field which I can reimplement to my liking. That's what I was looking for.