Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99733
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain opensides.be designates 195.154.20.141 as permitted sender)
To: internals@lists.php.net
Date: Tue, 04 Jul 2017 09:19:53 +0200
Message-ID: <4837555.saN6ZvxSLO@mcmic-probook>
Organization: OpenSides
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <b47c4e03-cab5-cffc-8479-968329da3a2f@heigl.org>
References: <2963553.WttLOBJENj@mcmic-probook> <16.D9.15131.F32CA595@pb1.pair.com> <b47c4e03-cab5-cffc-8479-968329da3a2f@heigl.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2315086.ahBTZ5VKQX"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] Re: [RFC] LDAP EXOP
From: come@opensides.be (=?ISO-8859-1?Q?C=F4me?= Chilliet)

--nextPart2315086.ahBTZ5VKQX
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Le mardi 4 juillet 2017, 07:03:20 Andreas Heigl a =C3=A9crit :
> > In my opinion the code is really ease to read with exceptions.
> >=20
> > try {
> >     $user =3D ldap_exop_whoami($link);
> > }
> > catch(Throwable $e) {
> > }
>=20
> 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 th=
e
> errors and leave moving to extensions for a later change. Partly to k=
eep
> at least some kind of consistency and partly to not come into the tra=
p
> of moving to extensions completely and therefore breaking BC=E2=80=A6=


For me moving to exception is an other subject that would need to be tr=
eated separately.
And I=E2=80=99m not even sure I would vote for that.

> > 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);
>=20
> 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, '');
>=20
> 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 th=
at
> is then returned.

This change to a random password.

> > 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])
>=20
> 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

Yeah same here, one function for each EXOP makes sense and I don=E2=80=99=
t see the point of splitting into two functions.
I don=E2=80=99t like the idea of switching oldpw and newpw order either=
 as it may confuse people.

> One thing though that I thought about: Chapter 4 of RFC 3062 explicit=
ly
> states that this function should only be available with confidentiall=
y
> support like TLS. So perhaps we should check whether the data will be=

> transfered via a secure connection and - if not - raise an error?

Hum I get the idea but is that really our place? I mean the API won=E2=80=
=99t prevent you from storing password without hashing for instance.
And people can use ldap_modify to change the password without TLS, whic=
h is equally dangerous IMO.
For me it should be possible, and useful at least for tests.

So for the API I will move to=20
string|FALSE ldap_exop_whoami(resource $link) - The returned string is
the DN of the currently bound user.

For ldap_exop_passwd, you proposed:
string|FALSE ldap_exop_passwd(resource $link [, string $user [, string
$oldPassword [, string $newPassword]]] - The returned string is the new=

password of the user. Either the given newPassword or a newly generated=
 one.

Does it makes sense to return the newPassword on success when it=E2=80=99=
s not generated? I think I would prefer if returning a string explicite=
ly means a password was generated, otherwise it gets too confused (3 po=
ssible meaning for the returned value!).

C=C3=B4me
--nextPart2315086.ahBTZ5VKQX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJZW0G8AAoJEKhk2MPOyw4ADG0P/10d/uy0jT7tQ0lmsI1JGHhT
siNubks7OTaqoRet/XRqjU4HYnuFnk/FCQ9lin7VPIHybk3h5m/y8HAXKuDz1psN
CiLnTEeDSfWKZNkU0JODGHFyRm9iBUl7Ejj8SwBls4VnwMTE6AGE7jn6ODh4u3pw
/oFLUtPNKdMSanVr4jfa+cIZLncaQlpPlm/rpZITpYIR3SyA+nWquhr8uN7x/mfo
YIpR6Iog36CmisFigMhzq17qItuj6GYf3iGFZvIq0KcdnyFm+jUsQ4edrzeQGWSZ
8gPkYOHguCCVV0gAXd94SDxKmYZqRQYZap5/k/h2uJSYcoyBAlezTvuwQW8WwqtS
UttKNouT+s8nwppqvDRHHKK0iBB2KME2OFKewpQWtV0IsFrc69R8pcBw3vhgXXKr
4S0zvoLUxmh/ZZ2ZLiopmrvTrCrMu48dP1vqC4PTkYjgQ5myWK6nMfA8M8DG1sHq
h4RSLHiSm7DlPpl/5HCrSKFh9rSHGYpLAHKvSNMtO97kQkLQ83cJ4JYeUcT+0t3k
62Y71XK/Kw3WIRQh01ZmKh4KaHOXaTbA+uzp//i2MLpH3uZQ/5f/5ETR6rdojHHM
7BeckW+dSbm08E7jHXEZ02+Zs3/qwLMSwrDaKx0wDQ6EewJPsWZxrHUn87TVfuj3
UJfq5k6qXxVdz8nq0oOm
=w9T0
-----END PGP SIGNATURE-----

--nextPart2315086.ahBTZ5VKQX--