Help migrating from JWT 3.3.3 to 5.2

[Duque2011]

Good afternoon devs.

I'm an almost junior dev (hahaha), and I've been in the field for about a year. To make sure I don't miss any work, I'm accepting all challenges.

The latest task that came my way is to update an entire API for a system. The big issue is that it was using JWT 3.3.3, and I'm having trouble making it work on 5.2 because a lot has changed.

Can anyone help if I share a screenshot of how it's currently configured?

[SvenRtbg]

I would suggest you follow the upgrade path: Version 3.4 should be helpful (it was when I worked on a similar task some years ago), and then go to 4.x and 5.x. This may sound like a lot of useless steps, but the library tries to send helpful deprecation and change comments (turn on the error level in PHP to E_ALL for them to surface in your tests).

Also read the docs. Especially the one valid for these earlier versions. And follow the upgrading steps: https://lcobucci-jwt.readthedocs.io/en/4.4.x/upgrading/

[Duque2011]

if($user){

            if($request->P_SYSTEM_ID == 1){
                $signer = new Sha256();
                $time = new DateTimeImmutable();
                $token = (new Builder())
                    ->withClaim('uid', $user->ID)
                    ->issuedAt($time)
                    //->expiresAt($time)
                    ->getToken($signer, new Key(env('JWT_SECRET')));
            }else{...

[SvenRtbg]

->expiresAt($time->modify('+30 minutes'))

Or the token would expire immediately

[Duque2011]

Success

[SvenRtbg]

Well... it automatically starts working once you do it right, doesn't it. :)

[Duque2011]

Now I'm moving on to the next step, migrating from version 3.4 to 4.0.

[Duque2011]

In which file should I make this change?

[Duque2011]

I'm in doubt about which of these two files I should do this.

[SvenRtbg]

It depends. The diffed file is a hypothetical example of your own code that tries to issue a token, and illustrates the necessary changes if you want to switch from providing all single parts towards configuring this config object somewhere and here using it. Note that this config object isn't magically created, and using it is definitely optional. I can't really remember if I used it - my use case was only consuming tokens created somewhere else, so I had no use to create tokens, and the config object seemed to provide no obvious benefit, instead it would ask for things like the private encryption key that I could not provide.

You have to assess what your use case is - and even if you use the library both ways, it might be your existing code is unwilling to be pushed into utilizing this config object, because you might not have central dependency injection, or whatever other reason you may encounter.

I believe migrating towards this config object is optional, if you are willing to do some steps manually. And it could be done later, once you reached 5.x.

[Duque2011]

See what I'm receiving. I think there's still something wrong.

[lcobucci]

The usage of the configuration object is indeed optional. It is useful when you have multiple places issuing and parsing tokens.

If that's not the case for you, then skip it.