| Package home | Report new bug | New search | Development Roadmap | Status: Open | Feedback | All | Closed Since Version 1.1.5 |
| Bug #2297 | truncated binary data | ||
|---|---|---|---|
| Submitted: | 2004-09-07 10:50 UTC | ||
| From: | martel at post dot pl | Assigned: | jw |
| Status: | Closed | Package: | Net_LDAP |
| PHP Version: | 4.3.8 | OS: | Gentoo 2004.0 |
| Roadmaps: | (Not assigned) | ||
[2004-09-07 10:50 UTC] martel at post dot pl
Description:
------------
Attribute binary data gets truncated if there is a character 0x00 present.
Reproduce code:
---------------
$params = array(
'scope' => 'sub',
'sizelimit' => 0,
'timelimit' => 10,
'attrsonly' => false,
'attributes' => array (
'guid',
'cn'
)
);
$srch =& $ldap->search('', '(objectclass=Person)', $params);
$en = $srch->shiftEntry();
$attrs = $en->attributes();
$attrs['guid'] = unpack('H*', $attrs['guid']);
var_dump::display($attrs);
Expected result:
----------------
You should see complete guids. The ones starting with zero are shown as empty strings and the rest is truncated on the first 0x00
Comments
[2004-10-01 10:33 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2004-10-01 11:02 UTC] martel at post dot pl
For now I have bypassed it through use of:
$en =& $srch->shiftEntry();
$tmp = ldap_get_values_len($ldap->_link, $srch->_elink, 'guid');
It's not pretty but it works.
And about my thoughts - in the next version you speak of, you could try pre-configure values that are stored in binary form and make sure they are taken by ldap_get_values_len. GUID for exmple is described as SYN_OCTET_STRING in NDS so it's always binary. I bet we can get a list of standard ldap binary attributes from the NDS somehow (if it can't be found in smoe of the RFCs).
And at least you could put the binary field names as a config parameter. Then the user would choose whether to get attribute by values_len or vanilla values.
[2004-10-01 11:27 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2004-10-07 13:23 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2004-10-12 11:37 UTC] martel at post dot pl
Well, I'm afraid it's still not working properly:
$srch =& $ldap->search('', '(objectClass=Organizational Unit)', $params);
if (Net_LDAP::isError($srch)) {
trigger_error($srch->getMessage(), E_USER_WARNING);
}
while ($en =& $srch->shiftEntry()) {
var_dump::display($en->dn());
//var_dump::display($en->getValues());
var_dump::display($en->getValue('guid'));
var_dump::display(unpack("H*", $en->getValue('guid')));
}
Among the values I get for example the guid 80a993b902e7d411bd4f instead of 80a993b902e7d411bd4f000255588efb. Truncated at first \x00 again.
PS: A 'single' option in the getValue method was a great idea. Thanks :)
[2004-10-13 14:13 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2004-10-14 07:39 UTC] martel at post dot pl
Before we go, I have to tell you that the schema of the guid was unexistent (it gave an Net LDAP Error) until I have made an LDAP mapping of 'guid' to GUID (hence the alias in schema). I have checked if that was the problem with not getting the guid earlier but still no go.
Here is the guid schema:
array(12) {
aliases => array(1) {
0 => string(4) guid
}
oid => string(29) 2.16.840.1.113719.1.1.4.1.501
name => string(4) grid
desc => string(18) Standard Attribute
syntax => string(33) 1.3.6.1.4.1.1466.115.121.1.40{16}
single-value => int 1
no-user-modification => int 1
x-nds_public_read => string(1) 1
x-nds_not_sched_sync_immediate => string(1) 1
x-nds_lower_bound => string(2) 16
max_length => string(2) 16
type => string(9) attribute
}
And here is my NDS Person object (I have altered any personal data in the output so the character count isn't correct in the output).
array(11) {
isManager => string(5) FALSE
manager => string(32) cn=AW,ou=IT,o=HQR
mail => string(29) MM@pro-futuro.com
guid => string(0)
givenname => string(6) Michal
fullname => string(15) Michal M
lastlogin => string(15) 20041013125728Z
title => string(37) Administrator Serwisow Internetowych
surname => string(7) M
uid => string(14) MM
}
Since the guid is binary this dump above is useless. And after issueing this var_dump:
var_dump::display(unpack('H*', $attrs['guid']));
We get:
array(1) {
1 => string(0)
}
Which should print this: 000e44b4097bd71183c80002557cd268:
And this problem aside, you have a little bug in LDAP.php at line 992:
FATAL [/usr/lib/php/Net/LDAP.php:992] Use of undefined constant LDAP_ERROR - assumed 'LDAP_ERROR'
I guess it should be NET_LDAP_ERROR.
PS. Please implement a sort function as you have altered the code and my sorting trick does not work at the moment ;)
PPS: Maybe we should start e-mailing each other directly since it would be a lot more covenient. What do you think?
[2004-11-12 19:03 UTC] shaffin_bhanji at yahoo dot ca
Emailing each other directly defeats the purpose of understanding the history behind the change/bugfix that was implemented.
In my opinion I find the history of the conversation very intuitive and not to mention that others highly appreciate the work that goes into this product and others for that matter.
THANK YOU FOR BEING HEARD AND FOR ALL THE GOOD WORK THAT YOU GUYS ARE PUTTING IN!! :)
[2004-11-18 13:13 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2004-11-18 13:15 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2004-11-18 13:16 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2004-11-18 13:19 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!