rfc:ldap_exop
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:ldap_exop [2017/06/27 07:35] – mcmic | rfc:ldap_exop [2017/06/29 14:24] – mcmic | ||
---|---|---|---|
Line 29: | Line 29: | ||
This RFC also wish to introduce helper functions for common EXOP usage: | This RFC also wish to introduce helper functions for common EXOP usage: | ||
<code php> | <code php> | ||
- | mixed ldap_exop_whoami(resource $link) | + | bool ldap_exop_whoami(resource $link, string & |
bool ldap_exop_passwd(resource $link, string $user, string $oldpw, string $newpw [, string & | bool ldap_exop_passwd(resource $link, string $user, string $oldpw, string $newpw [, string & | ||
</ | </ | ||
Line 92: | Line 92: | ||
===== Open Issues ===== | ===== Open Issues ===== | ||
- Should the function names contain the word " | - Should the function names contain the word " | ||
- | - Should we include a constant for LDAP_EXOP_REFRESH, for the sake of completeness, | + | - Should we include a constant for LDAP_EXOP_CANCEL, for the sake of completeness, |
- Should helper functions return a mixed, or a boolean and have an out parameter? (" | - Should helper functions return a mixed, or a boolean and have an out parameter? (" | ||
- 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? | - 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//). | ||
+ | - 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? | ||
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== |
rfc/ldap_exop.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1