Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heigl.org designates 195.191.240.18 as permitted sender)
To: Andreas Treichel <gmblar@gmail.com>, internals@lists.php.net
References: <2963553.WttLOBJENj@mcmic-probook>
 <D9.81.15131.6EC5A595@pb1.pair.com>
 <9a0b9d93-a8bd-0da0-dc16-971eb5d0c448@heigl.org>
 <16.D9.15131.F32CA595@pb1.pair.com>
Openpgp: id=967CCFA50DFFEE03BB8BF5F2CA9213C75BFCE472
Message-ID: <b47c4e03-cab5-cffc-8479-968329da3a2f@heigl.org>
Date: Tue, 4 Jul 2017 07:03:20 +0200
MIME-Version: 1.0
In-Reply-To: <16.D9.15131.F32CA595@pb1.pair.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="ocw74gX5dCdfxOianemQAecBiEtF0x18L"
Subject: Re: [PHP-DEV] Re: [RFC] LDAP EXOP
From: andreas@heigl.org (Andreas Heigl)

--ocw74gX5dCdfxOianemQAecBiEtF0x18L
Content-Type: multipart/mixed; boundary="Oh8hswtrcbARkgBOoVUBtQJHxmmFD7Dui";
 protected-headers="v1"
From: Andreas Heigl <andreas@heigl.org>
To: Andreas Treichel <gmblar@gmail.com>, internals@lists.php.net
Message-ID: <b47c4e03-cab5-cffc-8479-968329da3a2f@heigl.org>
Subject: Re: [PHP-DEV] Re: [RFC] LDAP EXOP
References: <2963553.WttLOBJENj@mcmic-probook>
 <D9.81.15131.6EC5A595@pb1.pair.com>
 <9a0b9d93-a8bd-0da0-dc16-971eb5d0c448@heigl.org>
 <16.D9.15131.F32CA595@pb1.pair.com>
In-Reply-To: <16.D9.15131.F32CA595@pb1.pair.com>

--Oh8hswtrcbARkgBOoVUBtQJHxmmFD7Dui
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hey Andreas.

Am 04.07.17 um 00:16 schrieb Andreas Treichel:
> Hey C=C3=B4me, hey Andreas.
>=20
>> string|FALSE ldap_exop_whoami(resource $link) - The returned string is=

>> the DN of the currently bound user.
>=20
> In my opinion the code is really ease to read with exceptions.
>=20
> try {
>     $user =3D ldap_exop_whoami($link);
> }
> catch(Throwable $e) {
> }

It definitely is easier to read. But let's not try too much in one go.
As all of the current extension uses errors I'd currently stick to the
errors and leave moving to extensions for a later change. Partly to keep
at least some kind of consistency and partly to not come into the trap
of moving to extensions completely and therefore breaking BC=E2=80=A6
>=20
>> string|FALSE ldap_exop_passwd(resource $link [, string $user [, string=

>> $oldPassword [, string $newPassword]]] - The returned string is the ne=
w
>> password of the user. Either the given newPassword or a newly
>> generated one.
>=20
> Change password of current user with a random password.
> ldap_exop_passwd($link);
>=20
> Change password of $user with a random password.
> ldap_exop_passwd($link, $user);
>=20
> Change $oldPassword of $user with a random password.
> ldap_exop_passwd($link, $user, $oldPassword);
>=20
> Change $oldPassword of $user to $newPassword.
> ldap_exop_passwd($link, $user, $oldPassword, $newPassword);
>=20
> As i wrote the four samples, i actually already like the ordering of th=
e
> arguments as it seems to make sense.
>=20
>=20
> How is the behavior of the following?
>=20
> Change $oldPassword of current user to $newPassword?
> ldap_exop_passwd($link, '', $oldPassword, $newPassword)
ldap_exop_passwd($link, null, $oldPassword, $newPassword);

Though passing an empty string should work also with the current code.
But I'd prefer to pass NULL
>=20
> Change $oldPassword of $user to empty string? Or random? Or is this an
> error?
> ldap_exop_passwd($link, $user, $oldPassword, '');

IMHO you can't change to an empty string. Because that would be like not
setting a password at all. I'd restrict that so far that providing an
empty password will cause the server to generate a random password that
is then returned.
>=20
>=20
> My previous suggestion was to split the function into two versions to
> reduce the amount of arguments.
>=20
> string|FALSE ldap_exop_passwd(resource $link, string $user, string
> $newPassword [, string $oldPassword])
>=20
> string|FALSE ldap_exop_random_passwd(resource $link, string $user [,
> string $oldPassword])

I would not do that as it bloats the API in an - in my eyes -
unnecessary way. Let's stick to one function for changing password=E2=80=A6=


One thing though that I thought about: Chapter 4 of RFC 3062 explicitly
states that this function should only be available with confidentially
support like TLS. So perhaps we should check whether the data will be
transfered via a secure connection and - if not - raise an error?

Cheers

Andreas

--=20
                                                              ,,,
                                                             (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50=C2=B022'59.5" E 08=C2=B0=
23'58" |
| http://andreas.heigl.org                       http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca                                               |
+---------------------------------------------------------------------+


--Oh8hswtrcbARkgBOoVUBtQJHxmmFD7Dui--

--ocw74gX5dCdfxOianemQAecBiEtF0x18L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEENHMr85T+FLwCJRBgjNqPc6i4Q/AFAllbIZgACgkQjNqPc6i4
Q/DGGhAAjrj9FMzqV9dA+Mw0pkZ7WEqhquxx3+BWlBNKeTx9E/7RUzZM0codj79J
adEtDHfZLcYVl7+RrCScQmYl7djChw64TqZge6NlcNj3l2cl8FVnIbvmB5viLVDr
Mu+GRVZ9BiroeZe3wAZr9j7o/TssLWBDQpsD0+6z844lAURNYAbTAWUeynWggXuA
njzXFpFOU3/Kkztrmg1lIPJs+oGzO7B0yoIEasXbov6ivQEpj4VD2wJWcH8TNdW5
ocv/18EjPR1nMotH7H62XUsNQtd+5hPvF6a6LZzidHUIipQz9Ij+Y5HZKTw/1ZLx
8iDsk7dHK/zgVupO33ZlfZxGKbPbnkO/ifjW+gFNjYQuNlK1HI1Nh+eFyLM4Fdcf
pyO80negfhPTc2B+eaXm381IgBYwmbNkN1MOeJhj4KyuHjmgf4diiU3G9zli8jBb
PxwPnx9Cqs/k5GstH3qRjqIoiOvF9VBDc2cZTP1hi7oZIgEe9MJqL7ASROaJHJX1
40Zs0r89VMwP62eMcmOljE5DiJxQ0KkDM3uwlkscOhVeFsqZy417d8c7fqmV1YtI
BWwjBPMDkuQzyGCsmr51qEihQwJ0p+nveBe4yTz0sD2CtdJIPVlFQWy/CddrH1ZS
gaxWGL2pHpm3JAHqLTxy2Aawt7AgPWY1+ytdSUY50dSW0LSNufU=
=Uie3
-----END PGP SIGNATURE-----

--ocw74gX5dCdfxOianemQAecBiEtF0x18L--