line1
line2
line3
line4
line5
Hi, (I'm sending this for N-th time as the other posts to dev-list
disappeared somewhere..)
Example of the bug, present in all versions of OpenSRS client after
XML protocol were introduced:
For example do a bulk order for 2 domains and use "&" in your
password.
Result - the two domains will go to separate profiles. You will not be
able to login to the second as the password is not what you expect.
(If for example it was "a&b" the second profile will have "a&b" as
a password; if there were 3 domains, the third would go to third
profile with "a&b" as a password)
---
This happens:
- in all fields (password, address, name, etc.)
- for the following chars: &,<,>,",', any with ord() > x80 (those with
x80 are unicoded, then the unicode characters are unicoded again etc -
like with the "&" transformation)
---
Another example: "<" -> "<" -> "&lt" -> "&amp;lt"
Or if you have street address like: "Street blabla" N.100 - it will be
OK for the first domain name, while the second will have "Street
blabla" N.100
Personally I noticed a long time ago the presence of " and other
things like this doing WHOIS, but guessed that this is caused by the
WHOIS server. Now it is clear it is caused by the bug, alive more than
a year...
---
OK, I consider this as a MAJOR BUG and can't believe no one noticed
it. After a week of waiting a response from the r3s3ll3r-supp0rt I am
really disappointed with them, as after I described exactly WHY this
happens I got a reply "the system has always treated symbols this way,
as it's a function of the XML:Parser" etc. Which is not the case!
The problem is that a structure is created, then in a loop only one
field is changed (for example the domain name), and this is send to
the server, converted to XML. But before that sub quote_XML_chars()
from lib/XML_codec.pl encodes the chars I am talking above. OK well
but this is fine the first time; the second time this encodes again
already encoded fields of the structure. And while they are not
initialized again in the loop, you see the results I am talking above.
I don't know how it is possible for a programmer to write such a
thing, but anyway..
To fix this:
quote_XML_chars() is used in Tree2XML() which is used in
data_to_xml_string() which is used in encode() (from XML_Codec.pm)
This is called in send_data() from lib/OpenSRS/XML_Client.pm:
$data_to_send = $self->{_OPS}->encode( $message )
Change in sub send_data() from lib/OpenSRS/XML_Client.pm, 3d line:
my $message = shift;
to:
my $message2 = shift;
my $message = deep_copy($message2);
and add deep_copy to XML_Client.pm:
sub deep_copy {
my $this = shift;
if (not ref $this) {
$this;
} elsif (ref $this eq "ARRAY") {
[map deep_copy($_), @$this];
} elsif (ref $this eq "HASH") {
+{map { $_ => deep_copy($this->{$_}) } keys %$this};
} else { $this; }
}
---
And better one of the OpenSRS programmers read this instead of telling
me "You may wish to display a warning besides the password field
itself, or change the code to include error handling for those
characters". LOL. I guess they still didn't understand the problem is
not only with the password.
Hope you enjoyed that :) (And sorry for my bad English)
Best regards,
Doytchin Spiridonov mailto:[EMAIL PROTECTED]
http://www.WebYou.com Web Design and Development
