added support for leeway

[dgrijalva]

See #131

[itsjamie]

I would simply allow users to implement Leeway in their Claims object. If you would like to provide this, I think it can be accomplished by adding a private variable to the Standard Claims object that is set in the default parser.

[itsjamie]

I guess, I wouldn't make the struct a requirement for the interface. Often times that may just be empty.

[itsjamie]

This interface would stay the same.

[harshavardhana]

This interface should change IMO leeway is not part of claims it is part of validation of claims. In-fact you can even add options like how pyjwt provides like verify_iat : false etc. to skip iat verify.

[dgrijalva]

I'm sorta on the fence about this, too. It seems the most graceful way to tunnel options through to validator. We are currently missing validations on things like iss as well, since they require data provided by the user (implementer?). This approach would allow for expanding in that direction.

I think we can sign off 3.0 the way it is and continue working on this for the next update.

[itsjamie]

I agree with signing off on 3.0 the way it is. There is nothing stopping someone from using the Claims interface now to implement Leeway, and I don't see any reason why the addition of Leeway cannot be done in a backwards compatible way after 3.0 lands. 👍

Essentially, my issue with the way this was implemented is that you're changing the interface of the Valid() call to always require a struct full of options. Therefore, anytime someone calls Valid, Regardless of whether or not their specific implementation requires it, they'll need to pass these options through.

Thank you!

[dgrijalva]

I don’t think that’s the end of the world if nil is considered valid.

-dave

On Jun 16, 2016, at 2:23 PM, Jamie Stackhouse notifications@github.com wrote:

I agree with signing off on 3.0 the way it is. There is nothing stopping someone from using the Claims interface now to implement Leeway, and I don't see any reason why the addition of Leeway cannot be done in a backwards compatible way after 3.0 lands. 👍

Essentially, my issue with the way this was implemented is that you're changing the interface of the Valid() call to always require a struct full of options. Therefore, anytime someone calls Valid, Regardless of whether or not their specific implementation requires it, they'll need to pass these options through.

Thank you!

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #139 (comment), or mute the thread https://github.com/notifications/unsubscribe/AABcofYkpj8UDvtKjbDY8SkgYIqm-77Hks5qMb7bgaJpZM4I27Kz.

[dgrijalva]

Either way, 3.0 has shipped.

[lbyte00]

Perhaps behaviour of Parse and ParseWithClaims should change to support ValidationsOptions, otherwise they will be always nil and it introduces bugs. Been debugging this for couple of hours 🙂
https://github.com/dgrijalva/jwt-go/blob/master/token.go#L89
https://github.com/dgrijalva/jwt-go/blob/master/token.go#L93

[lbyte00]

There's now

[lbyte00]

Same here

[lbyte00]

Consider naming it "LeewaySeconds" to make it clear that it should be specified in seconds

[seriousben]

a time.Duration might even be better.

[coolaj86]

Is this moving forward?

[emil-simeonov-sauce]

Is leeway support going to be introduced anytime soon? Not having it in place is kind of a blocker for certain scenarios.

[haneev]

For future reference, a full working example can be found below. I struggled with this myself, and the trick I was missing, was to add the UnmarshalJSON func on the LeewayClaims struct.

type LeewayClaims struct {
	jwt.MapClaims
	Leeway int64
}

func (m *LeewayClaims) VerifyExpiresAt(cmp int64, req bool) bool {
	return m.MapClaims.VerifyExpiresAt(cmp - m.Leeway, req)
}

func (m *LeewayClaims) VerifyIssuedAt(cmp int64, req bool) bool {
	return m.MapClaims.VerifyIssuedAt(cmp + m.Leeway, req)
}

func (m *LeewayClaims) VerifyNotBefore(cmp int64, req bool) bool {
	return m.MapClaims.VerifyNotBefore(cmp + m.Leeway, req)
}

func (m *LeewayClaims) UnmarshalJSON(b []byte) error {
	var claims jwt.MapClaims
	err := json.Unmarshal(b, &claims)
	m.MapClaims = claims
	return err
}

func (m *LeewayClaims) Valid() error {
	vErr := new(jwt.ValidationError)
	now := time.Now().Unix()

	if m.VerifyExpiresAt(now, false) == false {
		vErr.Inner = errors.New("Token is expired")
		vErr.Errors |= jwt.ValidationErrorExpired
	}

	if m.VerifyIssuedAt(now, false) == false {
		vErr.Inner = errors.New("Token used before issued")
		vErr.Errors |= jwt.ValidationErrorIssuedAt
	}

	if m.VerifyNotBefore(now, false) == false {
		vErr.Inner = errors.New("Token is not valid yet")
		vErr.Errors |= jwt.ValidationErrorNotValidYet
	}

	if vErr.Errors == 0 {
		return nil
	}

	return vErr
}

leewayClaims := &LeewayClaims{
	MapClaims: jwt.MapClaims{},
	Leeway:    60,
}
token, err := parser.ParseWithClaims(tokenString, leewayClaims, func(token *jwt.Token) (interface{}, error) { ...

[dgrijalva]

leeway support has landed on the 4.0 branch