An employee, whose last name is Null, kills our employee lookup app
stackoverflow.com
stackoverflow.com
(I speak in the past tense of SOAP because I am an optimist.)
(note, I too have long since abandoned SOAP)
They also massively over-engineered the endpoint, constantly wrapping elements within elements, for no real reason.
Naturally that line of reasoning didn't get very far with the “maintainers” of an internal purported-SSO system with a SOAP endpoint which crashed on non-ASCII data or SQL special characters in the submitted username / password values.
As we were testing, we found that some products in our database would cause a JSON decoding error on the Rails side. After a few minutes, we realized the problem. We had a string field for something (product IDs, manufacturer SKU, etc). On the PHP side, the JSON encoder was using PHP's is_numeric() for each field to see if the field was a number (to determine how to encode it). Some of the SKUs, however, happened to be composed entirely of digits, and for those, PHP encoded them into the JSON as integer values. This, of course, broke on the Rails end, because Rails was expecting a string value and got an integer value.
In the end, we had to write a surprising amount of code to work around the brain damage involved, since regardless of what we tried to do PHP wanted, by default, to send things as integers whenever possible. I believe the final fix was to actually patch the JSON encoder library and special-case that field.
is_int() checks the type of the field, while is_numeric() looks for strings that look like numbers.
You will also need to use settype() when getting your data from the database since integers from the database will pass through as strings (since the database range and PHP range aren't necessarily the same, use a float if you need unsigned ints).
Or just use the built in json_encode().
what.
A float can store an exact integer of up to 53 bits even on a 32 bit machine.
PHP only has signed ints. If you need to store an unsigned int you can either store it internally as signed and only convert it to unsigned with printf() when you output it (and deal with the complexity of comparisons), or use a float and limit yourself to 53 bits.
If you have a 64 bit machine then of course you can easily fit an unsigned 32 bit int in that range. But it's wise not to rely on that at least for another few years.
In short, if you need more than 32 signed bits of range, and you want to make sure your code will run on any machine, then use a float. If you know you only use 64 bit machines then you have more flexibility. (You can use PHP_INT_SIZE and PHP_INT_MAX to check.)
If you need even more range than that then use the built in GMP library.
Also, PHP will automatically convert numbers that are too large from ints to float, so normally you don't see any of this. It's only if you use settype() to force an int that you have to pay attention to this.
If the operation and the datatype's range are not equal, then you can indicate failure inside the return value by applying special meaning to invalid values. But if the operation and the datatype's range are equal, then you need another distinct value to indicate failure. The difficulty is in recognizing which situation you're in, and as you point out, this is one where, effectively, the operation and the datatype have the same range.
You can kind of get a flavor of what pre-enterprise-jackassery SOAP was like to work with by looking at Dave Winer's XML-RPC (spec: http://xmlrpc.scripting.com/spec.html), which was one of the precursors of SOAP.
It's hard for people to imagine now, but at the time the Internet was just one of many competing network standards. Had this been developed after the rise of the web, I'm sure it would have been a very different protocol.
(And SMTP, gopher, and finger were developed before the rise of the Web.)
http://en.wikipedia.org/wiki/Tim_Howes
The first real browser, Mosaic, was released the same year.
Eventually Howes went to Netscape, but Netscape didn't exist until 1994, and Howes didn't join them until 1996
"I trust that the guys who wrote this have been shot." :-)
People who all run the same version of Visual Studio think SOAP is awesome. Get handed somebody else's "whiz-dull" a few times, and see how much fun it is to generate a working client using a different brand/version client stack.
I'll admit I can't figure how they got to 'S' from there, however.
But a last name of 'Null' may be even better. :)
I MX’d the mail over to a friend’s spam-detection system for about 4 hours one time, but the volume crashed his server and he asked for relief.
Any system administrator looking at that will either be amused or search for the error in his date time parser.
He had some limited exposure to development in the past and had got into his head that this date was the Universal Developer Test Date.
Careful about picking a low-populated area like this. I used to live in a town with population of about 2,000 and the post office clerks knew most everyone by name. One time I signed up for a site and just used "123 Blah St." as a placeholder address. Months later, some letter was mailed to that address, but the mail clerk, recognizing my name, just helpfully put it in my PO Box anyway!
Often, names alone wouldn't necessarily constitute a violation as names are generally not sufficient to count as personally identifiable information... but a name like 'Bobby Null' is, I think, quite unique.
When I was being trained on HIPAA compliance I was told that sole first names are generally perfectly fine, and sole last names can often be fine but should be avoided for very common names. But I should also say that I am not an expert on HIPAA compliance.
All the post tells us is that a person named "Bobby Null" exists and has medical records, as do most people. It doesn't say anything about this persons medical issues/history at all.
I could learn more about someone by sitting a touch too close to the reception area at a doctor's office.
A name by itself, you are quite right, is not PHI. Thanks for the reminder!
http://caterina.net/archive/001011.html
Flickr cofounder Caterina Fake couldn't fly on Northwest Airlines because their system silently deleted her tickets.
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...
* No one has a name that is a reserved system keyword (Null, Nan, Unknown...)
Server '; DROP TABLE servertypes; --
I thought it was some sort of bug or attack and reported it to them. Here's the response I got:
"It's a nod to http://xkcd.com/327/
Hope you parameterized your queries ;)"
I love when companies do fun things like this.
XML itself only describes a text encoding, XML infoset describes node labeled trees, possibly graphs through xml:id and idref.
Unlike JSON it doesn't have a concept of null, it only has absence of a node. The authors of SOAP just invented a truly terrible way of mapping XML into a programming language's constructs (which are typically edge labeled trees with typed nodes).
XML is actually a decent data format for markup. Using it for other purposes (RPC format, configuration files, ...) usually doesn't end well.
I heard of similar story of a student in Birmingham whose license plate was 'null'.
if ($lastname) { ... }
This fails when $lastname="0". But I am constantly seeing perl code that does it.
if(defined $lastname) { ... }
There is a town famously called simply "Y" in France.
Generally I find that Python's avoidance of implicit string type conversions means that I almost never have this kind of bug in my Python.
On another note, `myvar is 0` is undefined behavior; Python implementations can perfectly legitimately return False for that even if myvar is, in fact, the integer 0. Try this, in Python 2.7.3:
>>> x = 257
>>> x is 257
False
>>> x = 257; x is 257
True
>>> 257 is 2**8 + 1
False
>>> 256 is 2**8
True
>>> x = 256
>>> x is 256
True
root@ , nobody@ and daemon@
They gave me "daemon". I've terminated that account long ago, but last I checked (6 years ago?), I could still retrieve emails and dial in using a modem using that account.
I've always wondered if SICP style scheme would cause these sort of problems.
It's hard to do in-band signaling properly, but often time you only have a single data channel and then you have no choice.
FTFY. It's certainly possible there's a bug in the library.
I wish I could listen in on a dinner conversation at Null house. They must have an interesting perspective about computers.
It is all about assumptions. OP assumed nobody would be called Null. MusicBrainz index assumes no band chose to name themselves "Various Artists" or "[unknown]". These are advisable but how to not assume that people have last names?
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...
Picture at http://www.arcfn.com/2008/05/importance-of-software-testing....