Completed
Branch MagicUser (b8f336)
by Patrick
03:44
created

LDAPUser::__get()   A

Complexity

Conditions 1
Paths 1

Size

Total Lines 4
Code Lines 2

Duplication

Lines 0
Ratio 0 %

Importance

Changes 1
Bugs 0 Features 0
Metric Value
cc 1
eloc 2
c 1
b 0
f 0
nc 1
nop 1
dl 0
loc 4
rs 10
1
<?php
2
namespace Auth;
3
4
class LDAPUser extends User
5
{
6
    use LDAPCachableObject;
7
8
    private $ldapObj;
9
    private $server;
10
11
    public function __construct($data = false)
12
    {
13
        $this->server = \LDAP\LDAPServer::getInstance();
14
        if($data !== false && !isset($data['dn']) && !isset($data['extended']))
15
        {
16
            //Generic user object
17
            $filter = new \Data\Filter('mail eq '.$data['mail']);
18
            $users = $this->server->read($this->server->user_base, $filter);
19
            if($users === false || !isset($users[0]))
20
            {
21
                throw new \Exception('No such LDAP User!');
22
            }
23
            $this->ldapObj = $users[0];
24
        }
25 View Code Duplication
        else
0 ignored issues
show
Duplication introduced by
This code seems to be duplicated across your project.

Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation.

You can also find more detailed suggestions in the “Code” section of your repository.

Loading history...
26
        {
27
            if(isset($data['extended']))
28
            {
29
                $this->ldapObj = $data['extended'];
30
            }
31
            else
32
            {
33
                $this->ldapObj = $data;
34
            }
35
        }
36
    }
37
38
    private function check_child_group($array)
39
    {
40
        $res = false;
41
        for($i = 0; $i < $array['count']; $i++)
42
        {
43
            if(strpos($array[$i], $this->server->group_base) !== false)
44
            {
45
                $dn = explode(',', $array[$i]);
46
                $res = $this->isInGroupNamed(substr($dn[0], 3));
47
                if($res)
48
                {
49
                    return $res;
50
                }
51
            }
52
        }
53
        return $res;
54
    }
55
56
    /**
57
     * @param string $listName The name of the list to search
58
     * @param Group $group The group to search inside
59
     * @param string $dn The distringuished name to search for
60
     */
61
    private function isInListOrChild($listName, $group, $dn)
62
    {
63
        if(!isset($group[$listName]))
64
        {
65
            return false;
66
        }
67
        if(in_array($dn, $group[$listName]))
68
        {
69
            return true;
70
        }
71
        return $this->check_child_group($group[$listName]);
72
    }
73
74
    public function isInGroupNamed($name)
75
    {
76
        $filter = new \Data\Filter('cn eq '.$name);
77
        $group = $this->server->read($this->server->group_base, $filter);
78
        if(!empty($group))
79
        {
80
            $group = $group[0];
81
            $dn  = $this->ldapObj->dn;
82
            $uid = $this->ldapObj->uid[0];
83
            $ret = $this->isInListOrChild('member', $group, $dn);
84
            if($ret === false)
85
            {
86
                $ret = $this->isInListOrChild('uniquemember', $group, $dn);
87
            }
88
            if($ret === false && isset($group['memberUid']) && in_array($uid, $group['memberUid']))
89
            {
90
                return true;
91
            }
92
            return $ret;
93
        }
94
        return false;
95
    }
96
97
    public function __get($propName)
98
    {
99
        return $this->getFieldSingleValue($propName);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue($propName); (string) is incompatible with the return type of the parent method Auth\User::__get of type boolean.

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...
100
    }
101
102
    public function __set($propName, $value)
103
    {
104
    }
105
106
    public function getEmail()
107
    {
108
        return $this->getFieldSingleValue('mail');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('mail'); (string) is incompatible with the return type of the parent method Auth\User::getEmail of type boolean.

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...
109
    }
110
111
    public function getUid()
112
    {
113
        return $this->getFieldSingleValue('uid');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('uid'); (string) is incompatible with the return type of the parent method Auth\User::getUid of type boolean.

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...
114
    }
115
116
    public function getPhoto()
117
    {
118
        return $this->getFieldSingleValue('jpegPhoto');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('jpegPhoto'); (string) is incompatible with the return type of the parent method Auth\User::getPhoto of type boolean.

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...
119
    }
120
121
    public function getPhoneNumber()
122
    {
123
        return $this->getFieldSingleValue('mobile');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('mobile'); (string) is incompatible with the return type of the parent method Auth\User::getPhoneNumber of type boolean.

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...
124
    }
125
126
    public function getOrganization()
127
    {
128
        $org = $this->getFieldSingleValue('o');
129
        if($org === false)
130
        {
131
            return 'Volunteer';
0 ignored issues
show
Bug Best Practice introduced by
The return type of return 'Volunteer'; (string) is incompatible with the return type of the parent method Auth\User::getOrganization of type boolean.

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...
132
        }
133
        return $org;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $org; (string) is incompatible with the return type of the parent method Auth\User::getOrganization of type boolean.

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...
134
    }
135
136
    public function getTitles()
137
    {
138
        $titles = $this->getField('title');
139
        if(isset($titles['count']))
140
        {
141
            unset($titles['count']);
142
        }
143
        return $titles;
144
    }
145
146
    public function getState()
147
    {
148
        return $this->getFieldSingleValue('st');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('st'); (string) is incompatible with the return type of the parent method Auth\User::getState of type boolean.

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...
149
    }
150
151
    public function getCity()
152
    {
153
        return $this->getFieldSingleValue('l');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('l'); (string) is incompatible with the return type of the parent method Auth\User::getCity of type boolean.

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...
154
    }
155
156
    public function getLastName()
157
    {
158
        return $this->getFieldSingleValue('sn');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('sn'); (string) is incompatible with the return type of the parent method Auth\User::getLastName of type boolean.

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...
159
    }
160
161
    public function getNickName()
162
    {
163
        return $this->getFieldSingleValue('cn');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('cn'); (string) is incompatible with the return type of the parent method Auth\User::getNickName of type boolean.

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...
164
    }
165
166
    public function getAddress()
167
    {
168
        return $this->getFieldSingleValue('postalAddress');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSi...Value('postalAddress'); (string) is incompatible with the return type of the parent method Auth\User::getAddress of type boolean.

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...
169
    }
170
171
    public function getPostalCode()
172
    {
173
        return $this->getFieldSingleValue('postalCode');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('postalCode'); (string) is incompatible with the return type of the parent method Auth\User::getPostalCode of type boolean.

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...
174
    }
175
176
    public function getCountry()
177
    {
178
        return $this->getFieldSingleValue('c');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->getFieldSingleValue('c'); (string) is incompatible with the return type of the parent method Auth\User::getCountry of type boolean.

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...
179
    }
180
181
    public function getOrganizationUnits()
182
    {
183
        $units = $this->getField('ou');
184
        if(isset($units['count']))
185
        {
186
            unset($units['count']);
187
        }
188
        return $units;
189
    }
190
191
    public function getLoginProviders()
192
    {
193
        $hosts = $this->getField('host');
194
        if(isset($hosts['count']))
195
        {
196
            unset($hosts['count']);
197
        }
198
        return $hosts;
199
    }
200
201
    public function getGroups()
202
    {
203
        $res = array();
204
        $groups = $this->server->read($this->server->group_base);
205
        if(!empty($groups))
206
        {
207
            $count = count($groups);
208
            for($i = 0; $i < $count; $i++)
209
            {
210
                if($this->isInGroupNamed($groups[$i]['cn'][0]))
211
                {
212
                    array_push($res, new LDAPGroup($groups[$i]));
213
                }
214
            }
215
            return $res;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $res; (array) is incompatible with the return type of the parent method Auth\User::getGroups of type boolean.

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...
216
        }
217
        else
218
        {
219
            return false;
220
        }
221
    }
222
223
    public function addLoginProvider($provider)
224
    {
225
        return $this->appendField('host', $provider);
226
    }
227
228
    private function generateLDAPPass($pass)
229
    {
230
        mt_srand((double)microtime() * 1000000);
231
        $salt = pack("CCCC", mt_rand(), mt_rand(), mt_rand(), mt_rand());
232
        $hash = base64_encode(pack('H*', sha1($pass.$salt)).$salt);
233
        return '{SSHA}'.$hash;
234
    }
235
236
    public function setPass($password)
237
    {
238
        if(!is_object($this->ldapObj))
239
        {
240
            return $this->setFieldLocal('userPassword', $this->generateLDAPPass($password));
241
        }
242
        else
243
        {
244
            $obj = array('dn'=>$this->ldapObj->dn);
245
            $obj['userPassword'] = $this->generateLDAPPass($password);
246
            if(isset($this->ldapObj->uniqueidentifier))
247
            {
248
                $obj['uniqueIdentifier'] = null;
249
            }
250
            //Make sure we are bound in write mode
251
            $auth = \AuthProvider::getInstance();
252
            $ldap = $auth->getMethodByName('Auth\LDAPAuthenticator');
253
            $ldap->get_and_bind_server(true);
254
            return $this->update($obj);
255
        }
256
    }
257
258
    public function validate_password($password)
259
    {
260
        if($this->server->bind($this->ldapObj->dn, $password))
261
        {
262
            return true;
263
        }
264
        return false;
265
    }
266
267
    public function validate_reset_hash($hash)
268
    {
269
        if(isset($this->ldapObj->uniqueidentifier) && strcmp($this->ldapObj->uniqueidentifier[0], $hash) === 0)
270
        {
271
            return true;
272
        }
273
        return false;
274
    }
275
276 View Code Duplication
    public static function from_name($name, $data = false)
0 ignored issues
show
Duplication introduced by
This method seems to be duplicated in your project.

Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation.

You can also find more detailed suggestions in the “Code” section of your repository.

Loading history...
277
    {
278
        if($data === false)
279
        {
280
            throw new \Exception('data must be set for LDAPUser');
281
        }
282
        $filter = new \Data\Filter("uid eq $name");
283
        $user = $data->read($data->user_base, $filter);
0 ignored issues
show
Bug introduced by
The method read cannot be called on $data (of type boolean).

Methods can only be called on objects. This check looks for methods being called on variables that have been inferred to never be objects.

Loading history...
284
        if($user === false || !isset($user[0]))
285
        {
286
            return false;
287
        }
288
        return new static($user[0]);
289
    }
290
291 View Code Duplication
    public static function from_dn($dn, $data = false)
0 ignored issues
show
Duplication introduced by
This method seems to be duplicated in your project.

Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation.

You can also find more detailed suggestions in the “Code” section of your repository.

Loading history...
292
    {
293
        if($data === false)
294
        {
295
            throw new \Exception('data must be set for LDAPUser');
296
        }
297
        $filter = new \Data\Filter("dn eq $dn");
298
        $user = $data->read($data->user_base, $filter);
0 ignored issues
show
Bug introduced by
The method read cannot be called on $data (of type boolean).

Methods can only be called on objects. This check looks for methods being called on variables that have been inferred to never be objects.

Loading history...
299
        if($user === false || !isset($user[0]))
300
        {
301
            return false;
302
        }
303
        return new static($user[0]);
304
    }
305
306
    public function setDisplayName($name)
307
    {
308
        return $this->setField('displayName', $name);
309
    }
310
311
    public function setGivenName($name)
312
    {
313
        return $this->setField('givenName', $name);
314
    }
315
316
    public function setLastName($sn)
317
    {
318
        return $this->setField('sn', $sn);
319
    }
320
321
    public function setEmail($email)
322
    {
323
        return $this->setField('mail', $email);
324
    }
325
326
    public function setUid($uid)
327
    {
328
        if(!is_object($this->ldapObj))
329
        {
330
            return $this->setFieldLocal('uid', $uid);
331
        }
332
        else
333
        {
334
            throw new \Exception('Unsupported!');
335
        }
336
    }
337
338
    public function setPhoto($photo)
339
    {
340
        return $this->setField('jpegPhoto', $photo);
341
    }
342
343
    public function setAddress($address)
344
    {
345
        return $this->setField('postalAddress', $address);
346
    }
347
348
    public function setPostalCode($postalcode)
349
    {
350
        $postalcode = trim($postalcode);
351
        return $this->setField('postalCode', $postalcode);
352
    }
353
354
    public function setCountry($country)
355
    {
356
        return $this->setField('c', $country);
357
    }
358
359
    public function setState($state)
360
    {
361
        return $this->setField('st', $state);
362
    }
363
364
    public function setCity($city)
365
    {
366
        return $this->setField('l', $city);
367
    }
368
369
    public function setPhoneNumber($phone)
370
    {
371
        return $this->setField('mobile', $phone);
372
    }
373
374
    public function setTitles($titles)
375
    {
376
        if(!is_array($titles))
377
        {
378
            $titles = array($titles);
379
        }
380
        return $this->setField('title', $titles);
381
    }
382
383
    public function setOrganizationUnits($ous)
384
    {
385
        if(!is_array($ous))
386
        {
387
            $ous = array($ous);
388
        }
389
        return $this->setField('ou', $ous);
390
    }
391
392
    public function flushUser()
393
    {
394
        if(is_object($this->ldapObj))
395
        {
396
            //In this mode we are always up to date
397
            return true;
398
        }
399
        $obj = $this->ldapObj;
400
        $obj['objectClass'] = array('top', 'inetOrgPerson', 'extensibleObject');
401
        $obj['dn'] = 'uid='.$this->ldapObj['uid'].','.$this->server->user_base;
402
        if(!isset($obj['sn']))
403
        {
404
            $obj['sn'] = $obj['uid'];
405
        }
406
        if(!isset($obj['cn']))
407
        {
408
            $obj['cn'] = $obj['uid'];
409
        }
410
        $ret = $this->server->create($obj);
411
        return $ret;
412
    }
413
414
    public function getPasswordResetHash()
415
    {
416
        //Make sure we are bound in write mode
417
        $auth = \AuthProvider::getInstance();
418
        $ldap = $auth->getMethodByName('Auth\LDAPAuthenticator');
419
        $ldap->get_and_bind_server(true);
420
        $ldapObj = $this->server->read($ldap->user_base, new \Data\Filter('uid eq '.$this->getUid()));
421
        $ldapObj = $ldapObj[0];
422
        $hash = false;
0 ignored issues
show
Unused Code introduced by
$hash is not used, you could remove the assignment.

This check looks for variable assignements that are either overwritten by other assignments or where the variable is not used subsequently.

$myVar = 'Value';
$higher = false;

if (rand(1, 6) > 3) {
    $higher = true;
} else {
    $higher = false;
}

Both the $myVar assignment in line 1 and the $higher assignment in line 2 are dead. The first because $myVar is never used and the second because $higher is always overwritten for every possible time line.

Loading history...
423
        if(isset($ldapObj->userpassword))
424
        {
425
            $hash = hash('sha512', $ldapObj->dn.';'.$ldapObj->userpassword[0].';'.$ldapObj->mail[0]);
426
        }
427
        else
428
        {
429
            $hash = hash('sha512', $ldapObj->dn.';'.openssl_random_pseudo_bytes(10).';'.$ldapObj->mail[0]);
430
        }
431
        $obj = array('dn'=>$this->ldapObj->dn);
432
        $obj['uniqueIdentifier'] = $hash;
433
        if($this->server->update($obj) === false)
434
        {
435
            throw new \Exception('Unable to create hash in LDAP object!');
436
        }
437
        return $hash;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $hash; (string) is incompatible with the return type of the parent method Auth\User::getPasswordResetHash of type boolean.

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...
438
    }
439
440
    public function delete()
441
    {
442
        //Make sure we are bound in write mode
443
        $auth = \AuthProvider::getInstance();
444
        $ldap = $auth->getMethodByName('Auth\LDAPAuthenticator');
445
        $ldap->get_and_bind_server(true);
446
        return $this->server->delete($this->ldapObj->dn);
447
    }
448
}
449
/* vim: set tabstop=4 shiftwidth=4 expandtab: */
450