JWT::__construct()   A
last analyzed

Complexity

Conditions 1
Paths 1

Size

Total Lines 12
Code Lines 5

Duplication

Lines 0
Ratio 0 %

Importance

Changes 0
Metric Value
cc 1
eloc 5
nc 1
nop 0
dl 0
loc 12
rs 9.4285
c 0
b 0
f 0
1
<?php
2
3
namespace Bludata\Lumen\Authentication\JWT\Libs;
4
5
use Bludata\Lumen\Authentication\JWT\Interfaces\JWTInterface;
6
use Exception;
7
use Lcobucci\JWT\Builder;
8
use Lcobucci\JWT\Parser;
9
use Lcobucci\JWT\Signer\Hmac\Sha256;
10
use Lcobucci\JWT\Token;
11
12
/**
13
 * Basic gadget for using of the JWT.
14
 *
15
 * @author Cristian B. dos Santos <[email protected]>
16
 */
17
class JWT implements JWTInterface
18
{
19
    /**
20
     * The builder token.
21
     *
22
     * @var Lcobucci\JWT\Builder
23
     */
24
    protected $builder;
25
26
    public function __construct()
27
    {
28
        $this->builder = new Builder();
0 ignored issues
show
Documentation Bug introduced by
It seems like new \Lcobucci\JWT\Builder() of type object<Lcobucci\JWT\Builder> is incompatible with the declared type object<Bludata\Lumen\Aut...s\Lcobucci\JWT\Builder> of property $builder.

Our type inference engine has found an assignment to a property that is incompatible with the declared type of that property.

Either this assignment is in error or the assigned type should be added to the documentation/type hint for that property..

Loading history...
29
30
        $this->builder
31
             ->setIssuer(gethostname())
32
             ->setId(time(), true);
33
             // ->setIssuedAt(time())
0 ignored issues
show
Unused Code Comprehensibility introduced by
63% of this comment could be valid code. Did you maybe forget this after debugging?

Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it.

The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production.

This check looks for comments that seem to be mostly valid code and reports them.

Loading history...
34
             // ->setNotBefore(time() + 60)
0 ignored issues
show
Unused Code Comprehensibility introduced by
50% of this comment could be valid code. Did you maybe forget this after debugging?

Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it.

The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production.

This check looks for comments that seem to be mostly valid code and reports them.

Loading history...
35
             // ->setExpiration(time() + 3600)
0 ignored issues
show
Unused Code Comprehensibility introduced by
50% of this comment could be valid code. Did you maybe forget this after debugging?

Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it.

The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production.

This check looks for comments that seem to be mostly valid code and reports them.

Loading history...
36
             // ->set('teste', 1);
0 ignored issues
show
Unused Code Comprehensibility introduced by
70% of this comment could be valid code. Did you maybe forget this after debugging?

Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it.

The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production.

This check looks for comments that seem to be mostly valid code and reports them.

Loading history...
37
    }
38
39
    /**
40
     * Create object of a token.
41
     *
42
     * @param array $user
43
     *
44
     * @return Lcobucci\JWT\Token
45
     */
46
    public function generateTokenByUser($user)
47
    {
48
        return $this->builder
49
                    ->set('user', $user)
50
                    ->sign(new Sha256(), env('JWT_SECRET'))
51
                    ->getToken();
52
    }
53
54
    /**
55
     * [Return the value of a token the request].
56
     *
57
     * @param string $token
58
     *
59
     * @return Lcobucci\JWT\Token
0 ignored issues
show
Documentation introduced by
Should the return type not be Token|null?

This check compares the return type specified in the @return annotation of a function or method doc comment with the types returned by the function and raises an issue if they mismatch.

Loading history...
60
     */
61
    public function decodeToken($token)
62
    {
63
        try {
64
            $parser = new Parser();
65
66
            if (!$token = $parser->parse((string) $token)) {
0 ignored issues
show
Coding Style introduced by
Consider using a different name than the parameter $token. This often makes code more readable.
Loading history...
67
                throw new Exception('Token inválido');
68
            }
69
70
            return $token;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $token; (Lcobucci\JWT\Token) is incompatible with the return type declared by the interface Bludata\Lumen\Authentica...TInterface::decodeToken of type Bludata\Lumen\Authentica...aces\Lcobucci\JWT\Token.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
71
        } catch (Exception $e) {
72
            abort(401, 'Favor efetuar o login novamente');
73
        }
74
    }
75
76
    /**
77
     * Verify is validate token in signature.
78
     *
79
     * @param Lcobucci\JWT\Token $token
0 ignored issues
show
Documentation introduced by
Should the type for parameter $token not be Token?

This check looks for @param annotations where the type inferred by our type inference engine differs from the declared type.

It makes a suggestion as to what type it considers more descriptive.

Most often this is a case of a parameter that can be null in addition to its declared types.

Loading history...
80
     *
81
     * @return bool
82
     */
83
    public function isValidByToken(Token $token)
84
    {
85
        return $token->verify(new Sha256(), env('JWT_SECRET'));
86
    }
87
}
88