Consider returning new JWT on decode

[rpcme]

I am having a difficult time managing JWTs when the decode method is stomping on values�. It also makes it difficult to test.

delete $self->{$_} for qw/claims expires not_before/;

Perhaps it may work to have the encode and decode methods be static.

[jberger]

that does sound intriguing, I'll give it a look soonish

[rpcme]

I guess the value of extending your module is when I can modify what ->claims produces. Right now, I basically override the claims attribute so ->encode can take values based on some set of behaviours the programmer needs as per google's (or other) rules.

unfortunately, it seems as though ->decode does enough damage where I can't even decode and look at exp (which makes it so I can't validate the value).

another option is $jwt->plan (surely there's some name far more correct than this), which produces the claim that would be encoded.

Most of this is talking out loud.

[jberger]

Yeah, I get your point. I was imagining that a user would create a new instance per message, in which case encode and decode make sense as they are, but that said, doing as you say would enforce that. I really do think it is worth consideration, I just haven't had a moment to look at it.

[rpcme]

Yep, no problem. Maybe we can hash it out next month.

On Apr 27, 2015, at 5:37 PM, Joel Berger [email protected] wrote:

Yeah, I get your point. I was imagining that a user would create a new instance per message, in which case encode and decode make sense as they are, but that said, doing as you say would enforce that. I really do think it is worth consideration, I just haven't had a moment to look at it.

—
Reply to this email directly or view it on GitHub #3 (comment).

[strangelittlemonkey]

Is this still in the works?

[jberger]

The thought is still on my mind yes, I just haven't seen much need to actually do it. If you are interested in presenting a patch, I'd consider it.