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 14:42] – 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 96: | Line 96: | ||
| - 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//). | - 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