I am trying to implement an oauth server and the package I am using needs the complete http.ResponseWriter and http.Request types.
c.Response does not contain all the methods that http.ResponseWriter does and c.Request gives error incompatible type.
How do I get http.ResponseWriter and http.Request in a Revel controller?
type client struct {
ClientId string
ClientSecret string
}
type App struct {
*revel.Controller
}
func (c App) TokenRequest() {
r := c.Request
w := c.Response
body, err := ioutil.ReadAll(r.Body)
if err != nil {
panic(err)
}
log.Println(string(body))
var cli client
err = json.Unmarshal(body, &cli)
if err != nil {
panic(err)
}
log.Println(cli.ClientId)
err = OauthSrv.HandleTokenRequest(w, r)
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
}
}
Warning
I am generally not fond of frameworks like Revel in Go, for reasons that I hope demonstrate themselves on this page. My first recommendation would be that you examine closely what you are actually getting out of Revel that merits the use of such a heavy abstraction layer, and if it's really that valuable, you may want to ask questions going in the other direction, such as how one might make OauthSrv work within Revel's customized ecosystem.
Using a Revel controller as a ResponseWriter
For something to be an http.ResponseWriter, it just needs to have these methods.
Header
You need a method named Header() that returns an http.Header, which you can build out of any map[string][]string. Revel provides similar functionality, but through several layers of abstraction. You will need to unravel them:
c.Response is a *Response, so it has a field named Out containing an OutResponse.
An OutResponse has a Header() method—but it doesn't return an http.Header. Instead, it returns a *RevelHeader.
A *RevelHeader has a GetAll(key string) []string method—which is very similar to the API already provided by the built-in map type, but isn't exactly the same. So, you will need to copy the returned values into a new map every time Header() is called, in order to fully satisfy the function signature requirements.
Also, GetAll() requires you to know the key name you are interested in, and *RevelHeader on its own does not provide a way to look up which keys are available. For now we can rely on the fact that the current implementation only has one field, a ServerHeader that does provide a GetKeys() []string method.
Putting all this together, we can build our Header method:
func (rrw RevelResponseWrapper) Header() http.Header {
revelHeader := rrw.Response.Out.Header()
keys := revelHeader.Server.GetKeys()
headerMap := make(map[string][]string)
for _, key := range keys {
headerMap[key] = revelHeader.GetAll(key)
}
return http.Header(headerMap)
}
Write and WriteHeader
You would use similar anti-patterns to expose rrw.Write([]byte) (int, error) so that it calls through to c.Response.Out.Write(data []byte) (int, error), and rrw.WriteHeader(int) error so that it calls c.Response.WriteHeader(int, string). Depending on what is considered appropriate for the framework, either panic on errors or fail silently, since their API doesn't expect WriteHeader errors to be handle-able.
Getting an http.Request from Revel
Unfortunately, the http.Request type is a struct, so you can't just simulate it. You basically have two options: reconstruct it using the net/http package from all the properties you are able to access, or hope that the *revel.Request you have is secretly an http.Request under the hood. In the latter case, you can use a type assertion:
revelReq, ok := c.Request.In.(*revel.GoRequest)
if !ok {
// handle this somehow
}
r := revelReq.Original
Related
I'm setting up a tcp server in a pet project I'm writing in go. I want to be able to maintain a slice of all connected clients, and then modify it whenever a new client connects or disconnects from my server.
My main mental obstacle right now is whether I should be declaring a package level slice, or just passing a slice into my handler.
My first thought was to declare my ClientList slice (I'm aware that a slice might not be my best option here, but I've decided to leave it as is for now) as a package level variable. While I think this would work, I've seen a number of posts discouraging the use of them.
My other thought was to declare ClientList as a slice in my main function, and then I pass ClientList to my HandleClient function, so whenever a client connects/disconnects I can call AddClient or RemoveClient and pass this slice in and add/remove the appropriate client.
This implementation is seen below. There are definitely other issues with the code, but I'm stuck trying to wrap my head around something that seems like it should be very simple.
type Client struct {
Name string
Conn net.Conn
}
type ClientList []*Client
// Identify is used to set the name of the client
func (cl *Client) Identify() error {
// code here to set the client's name in the based on input from client
}
// This is not a threadsafe way to do this - need to use mutex/channels
func (cList *ClientList) AddClient(cl *Client) {
*cList = append(*cList, cl)
}
func (cl *Client) HandleClient(cList *ClientList) {
defer cl.Conn.Close()
cList.AddClient(cl)
err := cl.Identify()
if err != nil {
log.Println(err)
return
}
for {
err := cl.Conn.SetDeadline(time.Now().Add(20 * time.Second))
if err != nil {
log.Println(err)
return
}
cl.Conn.Write([]byte("What command would you like to perform?\n"))
netData, err := bufio.NewReader(cl.Conn).ReadString('\n')
if err != nil {
log.Println(err)
return
}
cmd := strings.TrimSpace(string(netData))
if cmd == "Ping" {
cl.Ping() //sends a pong msg back to client
} else {
cl.Conn.Write([]byte("Unsupported command at this time\n"))
}
}
}
func main() {
arguments := os.Args
PORT := ":" + arguments[1]
l, err := net.Listen("tcp4", PORT)
if err != nil {
fmt.Println(err)
return
}
defer l.Close()
fmt.Println("Listening...")
// Create a new slice to store pointers to clients
var cList ClientList
for {
c, err := l.Accept()
if err != nil {
log.Println(err)
return
}
// Create client cl1
cl1 := Client{Conn: c}
// Go and handle the client
go cl1.HandleClient(&cList)
}
}
From my initial testing, this appears to work. I am able to print out my client list and I can see that new clients are being added, and their name is being added after Identify() is called as well.
When I run it with the -race flag, I do get data race warnings, so I know I will need a threadsafe way to handle adding clients. The same goes for removing clients when I add that in.
Are there any other issues I might be missing by passing my ClientList into HandleClient, or any benefits I would gain from declaring ClientList as a package level variable instead?
Several problems with this approach.
First, your code contains a data race: each TCP connection is served by a separate goroutine, and they all attempt to modify the slice concurrently.
You might try building your code with go build -race (or go install -race — whatever you're using), and see it crash by the enabled runtime checks.
This one is easy to fix. The most straightforward approach is to add a mutex variable into the ClientList type:
type ClientList struct {
mu sync.Mutex
clients []*Client
}
…and make the type's methods hold the mutex while they're mutating the clients field, like this:
func (cList *ClientList) AddClient(cl *Client) {
cList.mu.Lock()
defer cList.mu.Unlock()
cList.clients = append(cList.clients, o)
}
(If you will ever encounter the typical usage pattern of your ClientList type is to frequently call methods which only read the contained list, you may start using the sync.RWLock type instead, which allows multiple concurrent readers.)
Second, I'd split the part which "identifies" a client out of the handler function.
As of now, in the handler, if the identification fails, the handler exits but the client is not delisted.
I'd say it would be better to identify it up front and only run the handler once the client is beleived to be okay.
Also it supposedly worth adding a deferred call to something like RemoveClient at the top of the handler's body so that the client is properly delisted when the handler is done with it.
IOW, I'd expect to see something like this:
func (cl *Client) HandleClient(cList *ClientList) {
defer cl.Conn.Close()
err := cl.Identify()
if err != nil {
log.Println(err)
return
}
cList.AddClient(cl)
defer cList.RemoveClient(cl)
// ... the rest of the code
}
I noticed whilst writing some RESTful endpoints in Lambda, I had three models, and the handlers, were all identical. They take a request, fetch some data from a repository, and return the data as a response. The only thing which differed in each handler function, was the model instance. So I was thinking of ways of passing in the type and re-using the same functionality for marshalling the response into JSON etc.
If I have a pattern such as this:
type Handler struct {
model interface{}
repository
}
func (h *Handler) Fetch(request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
model := h.model
if err := h.repository.Fetch(id, &model); err != nil {
return ErrResponse(err, http.StatusInternalServerError)
}
return Response(map[string]interface{}{
"resource": model,
}, http.StatusOK)
}
Then calling this:
repository := NewRepository(tableName, connection)
handler := &helpers.Handler{repository, new(models.Client)}
I'm re-assigning model := h.model so that the struct itself doesn't become 'stateful', otherwise I'd have to worry about locking to ensure its thread safe. So I figured I could just re-assign it in the scope of the handler to avoid that.
This pattern seems to work okay, but I wondered if there were any potential downsides or pitfalls?
I am using auth0, and I have two clients (ios, react) and a Go backend API using go-auth0.
I followed the documentation and made a Verify method that looks like this:
func Verify(handle httprouter.Handle) httprouter.Handle {
return func(w http.ResponseWriter, r *http.Request, p httprouter.Params) {
auth0Domain := viper.GetString("auth0.issuer")
audience := []string{viper.GetString("auth0.audience")}
client := auth0.NewJWKClient(auth0.JWKClientOptions{URI: auth0Domain + ".well-known/jwks.json"}, nil)
configuration := auth0.NewConfiguration(client, audience, auth0Domain, jose.RS256)
validator := auth0.NewValidator(configuration, nil)
_, err := validator.ValidateRequest(r)
if err != nil {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusUnauthorized)
json.NewEncoder(w).Encode(map[string]string{"error": "Unauthorized"})
return
}
handle(w, r, p)
}
}
Unfortunately I notice that it takes ~400ms for the first verify, and subsequent ones take ~50ms.
However, if I initialize a struct with a field for the validator, move all the setup code into an Initialize(), then it takes only ~1ms:
func Verify(handle httprouter.Handle) httprouter.Handle {
return func(w http.ResponseWriter, r *http.Request, p httprouter.Params) {
_, err := a.validator.ValidateRequest(r)
if err != nil {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusUnauthorized)
json.NewEncoder(w).Encode(map[string]string{"error": "Unauthorized"})
return
}
handle(w, r, p)
}
}
Is this a bad idea to do? I am just learning about JWK today and looking at the auth0 code it seems they do construct a cache but I'm not entirely understanding how it works.
Can someone please let me know if moving the config into a struct and using its validator is a good idea?
UPDATE
auth0 has a builtin method to do this! Here's an example:
auth0.NewJWKClientWithCache(auth0.JWKClientOptions{URI: a.issuer + ".well-known/jwks.json"}, nil, auth0.NewMemoryKeyCacher(time.Duration(10)*time.Second, 5))
Use this method so it caches for you! :)
It should almost definitely be safe to cache the client object, and doing so tends to be a good idea in general. ("Create one client and reuse it" is a good general rule.)
My understanding is that the signing keys for JWTs are typically valid for months if not longer. (Auth0's documentation notes that its JWKS documents only ever have a single key, but it will issue signed tokens all the time, so the keys must be valid for "a while".) RFC 7517 doesn't define any expiration-related parameters on either a JWKS or an individual JWK, and I think the best practice is to use ordinary HTTP caching controls on the JWKS endpoint to refresh it occasionally, but not that often.
I would like to ask how we should approach the issue with context propagation in Golang.
My application is an HTTP JSON API server.
I would use the context as a container of informative data (e.g. the request id, some things I unpack from requests or from the process).
One of the dumbest advantages is to vehicle data and tags useful for statistics and logging. E.g. Be able to add at each log line the transaction id in all the packages I own
The problem I'm facing is the following:
func handleActivityY(w http.ResponseWriter, r *http.Request) {
info, err := decodeRequest(r)
...
stepOne, err := stepOne(r.Context(), info)
...
stepTwo, err := stepTwo(r.Context(), stepOne)
...
}
The problem with this design is the fact the context is an immutable entity (each time we add something or we set a new timeout, we have a new context).
The context cannot be propagated except returning the context at each function call (together with the return value, if any and the error).
The only way to make this work would be:
func handleActivityY(w http.ResponseWriter, r *http.Request) {
ctx, info, err := decodeRequest(r)
...
ctx, stepOne, err := stepOne(ctx, info)
...
ctx, stepTwo, err := stepTwo(ctx, stepOne)
...
}
I've already polluted almost any function in my packages with the context.Context parameter. Returning it in addition to other parameters seems to me overkill.
Is there really no other more elegant way to do so?
I am currently using the gin framework, which has its own context and it is mutable. I don't want to add the dependency to Gin for that.
Early in your context pipeline, add a mutable pointer to a data struct:
type MyData struct {
// whatever you need
}
var MyDataKey = /* something */
ctx, cancel := context.WithValue(context.Background(), MyDataKey, &MyData{})
Then in your methods that need to modify your data structure, just do so:
data := ctx.Value(MyDataKey)
data.Foo = /* something */
All normal rules about concurrent access safety apply, so you may need to use mutexes or other protection mechanisms if multiple goroutines can read/set your data value simultaneously.
Is there really no other more elegant way to do so?
stepOne could return it's own data independent of context and isolated from how the caller may use its information (ie put it in a databag/context and pass it to other functions)
func handleActivityY(w http.ResponseWriter, r *http.Request) {
ctx, info, err := decodeRequest(r)
...
stepOne, err := stepOne(ctx, info)
...
ctx = context.WithValue(ctx, "someContextStepTwoNeeds", stepOne.Something())
stepTwo, err := stepTwo(ctx, stepOne)
...
}
IMO data being passed request scoped should be extremely minimal contextual information
I've created a simple go program (basically just example code):
package main
import (
"fmt"
"io/ioutil"
"net/http"
)
func getPage(url string) (body []byte, err error) {
resp, err := http.Get(url)
body = nil
if (err != nil) {
return
}
defer resp.Body.Close()
body, err = ioutil.ReadAll(resp.Body)
return
}
func main() {
startUrl := "http://slashdot.org/"
body, err := getPage(startUrl)
if (err != nil) {
fmt.Println("Error: " , err)
}
fmt.Println(body)
}
I'm trying to go through the docs to understand how it all fits together.
First issue: http.Get(). It's not in the docs (at http://golang.org/pkg/net/http/). Except it is, but under Response. However there are 2 other Get() functions. How do I know that net/http.Get is actually the Get() on the Response type?
Anyway, so http.Get() returns a Response with a Body of io.ReadCloser. ioutil.ReadAll() takes an io.Reader - but how can I find other functions that accept this as a parameter? It kind of seems like the docs are 'backwards' - if I know which function I want I can find docs, but if I have a type, how can I find what functions will work with it?
The functions are defined like this :
func (c *Client) Get(url string) (resp *Response, err error)
func (h Header) Get(key string) string
func Get(url string) (resp *Response, err error)
See how functions are declared.
Between func and the name of the function (Get), you have the receiver type and name (between parenthesis). Only one of those functions has no receiver and must be called directly prefixed by the package name (http). That's the one you need.
Concerning your io.Reader and io.ReadCloser question:
Those are interfaces, if you are not familiar with them read up on them here
Interfaces are basically sets of methods, these two are defined as follows:
type Reader interface{
Read([]byte)(int, error)
}
type ReadCloser interface{
Read([]byte)(int, error)
Close()
}
This means any concrete datatype that has a Read Method with the above signature can be passed on as a io.Reader. A datatype that satisfies io.ReadCloser definitely does this, since it has to provide the Read method and an additional close Method.
So you can simply pass your ReadCloser on as Reader.
The way interfaces work in go is a little hard to grasp at the beginning since they are so implicit,
however they are very powerful and give you lot's of possibilities. Definitely read the text I linked above. I read the whole thing down, when I was starting with go and it made things a lot easier.