douhezi2285 2017-07-19 16:28
浏览 159
已采纳

jwtauth.Verifier失败

I'm trying to implement jwtauth but when the verify jwtoken is supposed to be activated a weird error happens.

So, as in the example they provide, we generate and return a token this way:

func (s *Service) loginEmployer(w http.ResponseWriter, r *http.Request) {
u := &User{}

    hashed, err := bcrypt.GenerateFromPassword([]byte(r.FormValue("password")), 8)
    if err != nil {
        panic(err)
    }

    tokenAuth = jwtauth.New("HS256", []byte(hashed), nil)
    _, tokenString, _ := tokenAuth.Encode(jwtauth.Claims{"login": r.FormValue("login")})
    u.TokenString = tokenString
    WriteJSON(w, u, 200)
} else {
    http.Error(w, http.StatusText(http.StatusUnauthorized), http.StatusUnauthorized)
}
}

The jwtauth.Verifier is declared as in the doc, global variable.

var tokenAuth *jwtauth.JwtAuth

func routes(s *Service) *chi.Mux {
// Private access login
r.Group(func(r chi.Router) {
    r.Use(jwtauth.Verifier(tokenAuth))
    r.Use(jwtauth.Authenticator)
    r.Mount("/employer", employerRoutes())
...

But when I try to access the routes within /employer, I get this error:

2017/07/19 18:16:22 http: panic serving 127.0.0.1:59856: runtime error: invalid memory address or nil pointer dereference
goroutine 15 [running]:
net/http.(*conn).serve.func1(0xc420019680)
    /usr/lib/go-1.8/src/net/http/server.go:1721 +0xd0
panic(0x7f9620, 0xa64510)
    /usr/lib/go-1.8/src/runtime/panic.go:489 +0x2cf
github.com/go-chi/jwtauth.(*JwtAuth).Decode(0x0, 0xc420192707, 0x67, 0x6, 0x6e, 0x0)
    /home/antiaskid/go/src/github.com/go-chi/jwtauth/jwtauth.go:168 +0x40
github.com/go-chi/jwtauth.VerifyRequest(0x0, 0xc4201aa400, 0xc420180b10, 0x1, 0x1, 0x0, 0x1, 0xc420180f30)
    /home/antiaskid/go/src/github.com/go-chi/jwtauth/jwtauth.go:124 +0x154
github.com/go-chi/jwtauth.Verify.func1.1(0xa40920, 0xc4201a8380, 0xc4201aa400)
    /home/antiaskid/go/src/github.com/go-chi/jwtauth/jwtauth.go:79 +0x89
net/http.HandlerFunc.ServeHTTP(0xc4201ae5c0, 0xa40920, 0xc4201a8380, 0xc4201aa400)
    /usr/lib/go-1.8/src/net/http/server.go:1942 +0x44
github.com/go-chi/chi.(*ChainHandler).ServeHTTP(0xc4201ae600, 0xa40920, 0xc4201a8380, 0xc4201aa400)
    /home/antiaskid/go/src/github.com/go-chi/chi/chain.go:29 +0x52
github.com/go-chi/chi.(*Mux).routeHTTP(0xc420192150, 0xa40920, 0xc4201a8380, 0xc4201aa400)
    /home/antiaskid/go/src/github.com/go-chi/chi/mux.go:415 +0x26d
github.com/go-chi/chi.(*Mux).(github.com/go-chi/chi.routeHTTP)-fm(0xa40920, 0xc4201a8380, 0xc4201aa400)
    /home/antiaskid/go/src/github.com/go-chi/chi/mux.go:351 +0x48
net/http.HandlerFunc.ServeHTTP(0xc4201808a0, 0xa40920, 0xc4201a8380, 0xc4201aa400)
    /usr/lib/go-1.8/src/net/http/server.go:1942 +0x44
main.(*Service).sessionMiddleware.func1(0xa40920, 0xc4201a8380, 0xc4201aa300)
    /home/antiaskid/go/src/bitbucket.org/victoria/middlewares.go:17 +0x148
net/http.HandlerFunc.ServeHTTP(0xc4201824e0, 0xa40920, 0xc4201a8380, 0xc4201aa300)
    /usr/lib/go-1.8/src/net/http/server.go:1942 +0x44
github.com/go-chi/chi.(*Mux).ServeHTTP(0xc420192150, 0xa40920, 0xc4201a8380, 0xc42000b000)
    /home/antiaskid/go/src/github.com/go-chi/chi/mux.go:80 +0x1df
net/http.serverHandler.ServeHTTP(0xc4201980b0, 0xa40920, 0xc4201a8380, 0xc42000b000)
    /usr/lib/go-1.8/src/net/http/server.go:2568 +0x92
net/http.(*conn).serve(0xc420019680, 0xa41020, 0xc420017300)
    /usr/lib/go-1.8/src/net/http/server.go:1825 +0x612
created by net/http.(*Server).Serve
    /usr/lib/go-1.8/src/net/http/server.go:2668 +0x2ce

Their example works fine, but the init is always happening. It's written that the Verify will take the token out of the header request as "Authorization", if I remove the verify and check the header, the token + header name are present (r.Header.Get("Authorization"))

Any has an idea about how to have it working?

  • 写回答

1条回答 默认 最新

  • duangelin7513 2017-07-19 17:55
    关注

    The problem I am seeing , which I may be incorrect, you are creating tokenAuth for each user that is logging in. There should be one instance of tokenAuth and you encode and decode using that instance. I believe the sign key should be the same for all the users, so you can verify from the tokenAuth instance. You might also want to look into signing it with RS256, because of issues in the past with HS256.

    https://auth0.com/blog/brute-forcing-hs256-is-possible-the-importance-of-using-strong-keys-to-sign-jwts/

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?