Remove package globals

[Michael Fridman]

There are a bunch of global variables throughout the package, if there's ever a time to move these as explicit args (or functional options), this might be the time?

Here are some that come to mind, maybe some of them make sense to keep, but figured it's worth discussing:

var TimePrecision = time.Second
var MarshalSingleStringAsArray = true
var DecodePaddingAllowed bool
var DecodeStrict bool

[Christian Banse]

Might be difficult however:

TimePrecision is used in MarshalJSON of NumericDate. No way to inject this somehow as a parser option.
MarshalSingleStringAsArray is basically the same, but for ClaimStrings.

DecodeStrict and DecodePaddingAllowed are used in DecodeSegment, which is a global function used by Parser (would be ok), but also by the signing methods.

Although this is actually really bad design because instead of giving the signing methods the already decoded signature, each signing method does it on its own. Basically, these lines are part of every signing method:

// Decode the signature
var sig []byte
if sig, err = DecodeSegment(signature); err != nil {
  return err
}

Changing this, would mean changing the public interface of SigningMethod; which we could do as part of the v5 release and I suspect that nobody is actually creating their own signing methods, so no code should break there I guess.

Moving the DecodeSegment to Parser and supplying the already base64-decoded signature to the signing method would also free us potentially in the future to pursue features like #168.

[Christian Banse]

To include all previous discussions, there was some concern about moving DecodeSegment in #153, but I guess the main problem there was exactly the point about having to do the encoding/decoding in the signing method and we might choose to keep those methods exported.

[Michael Fridman]

Hahaha, I gotta run to work... but that's exactly what I was exploring:

Moving the DecodeSegment to Parser and supplying the already base64-decoded signature to the signing method would also free us potentially in the future to pursue features like #168.

I think it'd be quite powerful if the caller had the opportunity to bring their own implementation.

I do however worry about the number of (breaking) changes we're making and whether this will deter user trust.

[Christian Banse]

Hahaha, I gotta run to work... but that's exactly what I was exploring:

Moving the DecodeSegment to Parser and supplying the already base64-decoded signature to the signing method would also free us potentially in the future to pursue features like #168.

I think it'd be quite powerful if the caller had the opportunity to bring their own implementation.

I do however worry about the number of (breaking) changes we're making and whether this will deter user trust.

I think the changes from an end-user perspective are not seeable. I see no good reason why anyone want to implement their own signing method. There are only a few accepted signing methods and as far as I know, we implement all of them.

Plus, its definitely a better design choice to leave en/decoding to the parser and signing/verifying to the signing method.

[Mikhail Mazurskiy]

Came to open this issue but it's here already. It'd be great to remove global mutable state. Imagine a program that needs to use this library with different settings in different areas of the program (e.g. TimePrecision). Today this is impossible.

p.s. thanks a lot for taking care of this library!