rfc:ldap_exop

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
rfc:ldap_exop [2017/06/29 14:24] – mcmicrfc:ldap_exop [2017/06/29 14:29] – mcmic
Line 32: Line 32:
 bool ldap_exop_passwd(resource $link, string $user, string $oldpw, string $newpw [, string &$genpw]) bool ldap_exop_passwd(resource $link, string $user, string $oldpw, string $newpw [, string &$genpw])
 </code> </code>
-The first one would call whoami EXOP and return either the result or FALSE upon failure.+The first one would call whoami EXOP and fill $result with the result. Return TRUE or FALSE upon failure.
 The second one would call passwd EXOP and return TRUE or FALSE upon failure. If $newpw is empty, $genpw will be filled with the generated password for the user. If $user is empty, it affects the bound user. The second one would call passwd EXOP and return TRUE or FALSE upon failure. If $newpw is empty, $genpw will be filled with the generated password for the user. If $user is empty, it affects the bound user.
  
Line 55: Line 55:
 } }
 // Same thing with the helper // Same thing with the helper
-$identity = ldap_exop_whoami($link); +if (ldap_exop_whoami($link, $identity)) {
-if ($identity !== FALSE) {+
   echo "Connected as $identity\n";   echo "Connected as $identity\n";
 } else { } else {
Line 93: Line 92:
   - Should the function names contain the word "exop" or is it a technical detail which should be hidden from the developer?   - Should the function names contain the word "exop" or is it a technical detail which should be hidden from the developer?
   - Should we include a constant for LDAP_EXOP_CANCEL, for the sake of completeness, even if this EXOP won’t be used by PHP code as all PHP LDAP operations are synchrone (in the current code state).   - Should we include a constant for LDAP_EXOP_CANCEL, for the sake of completeness, even if this EXOP won’t be used by PHP code as all PHP LDAP operations are synchrone (in the current code state).
-  - Should helper functions return a mixed, or a boolean and have an out parameter? ("mixed ldap_exop_whoami($link)" vs "bool ldap_exop_whoami($link, &$result)") 
-  - How would someone go about generating the needed ber-encoded data to pass ldap_exop in PHP? Should this RFC also define functions to handle ber-encoded data? 
   - The $retoid field seems useless for all EXOPs listed in the constant section, they either leave it empty or fill it with the same value as $reqoid. So maybe this field should be moved to the last position to be easily omitted. But this may result in a less natural order: //reqoid, reqdata, retdata, retoid// (though most of the time it will be //reqoid, reqdata, retdata//).   - The $retoid field seems useless for all EXOPs listed in the constant section, they either leave it empty or fill it with the same value as $reqoid. So maybe this field should be moved to the last position to be easily omitted. But this may result in a less natural order: //reqoid, reqdata, retdata, retoid// (though most of the time it will be //reqoid, reqdata, retdata//).
-  - How should error handling works? Original patch throws E_WARNING for all errors and failures, which seems a bad idea. Maybe filling the error so that error_get_last() gives the right information when a function of this RFC returns FALSE would be enough? Or should be uses exceptions?+  - Functions throws E_WARNING for all errors and failures. ldap_error() can be used to get the last error.
  
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
rfc/ldap_exop.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools