71–80 of 245 posts
"WSDL (SOAP) from AS3 to ColdFusion web service" I know it probably wasn't this guy's choice, but whooo boy.
Now, I'll admit, SOAP anything is crazy, but based on the age of the application, may have been the best option at the time.
"WSDL (SOAP) from AS3 to ColdFusion web service" I know it probably wasn't this guy's choice, but whooo boy.
I can't speak much to ColdFusion or WSDL though.
Earlier quoted context omitted.
My name fail to register surprisingly often, even here in Brazil. It is Hélder Maurício Gomes Ferreira Filho Common reasons for failure is being too long and having non ASCII characters, but sometimes it fails for other reasons, for example do not allow me to register without a middle name ( I don't haven't one actually... ), me confused and not knowing how to register Filho ( it is not a family name, neither a surna…
> "having non ASCII characters" Accented vowels are ASCII characters but in the extended set which people sometimes don't take account.
By contrast, there were national variants of ISO/IEC 646 (also a 7-bit character set, and essentially the internationalized version of ASCII) that included accented characters within those 128 code points. Generally these swapped out things like the at-sign (@) and the curly braces and vertical pipe character for accented vowels instead.
There were also lots of 8-bit character sets in ISO/IEC 8859 (e.g. Latin-1, or ISO/IEC 8859 part 1) that included accented characters within the "extended" set of code points 128-255.
A Japanese company once made the decision that they needed "virtual" employees in a particular system, for example to support e.g. adding a job to the org chart before that position had been filled (and another dozen use cases), so they had the clever idea "Hey, if we need to do this, we'll just input their 'name in Japanese' as one of a dozen status flags, like XX_JOB_REQUEST or XX_INCOMING_TRANSFER." One developer…
The org had 380K active entries, so it was definitely interesting being a dev on such a project, with a relatively common name, and conflicting dob and last 4-5 of my ssn.
We had a customer with the last name "Echo" who couldn't make a credit card payment. Turns out that the card processor was looking for strings which were common Unix commands and not allowing them.
Earlier quoted context omitted.
In our app we neither validate nor escape user strings for any free form text (eg. "names" and descriptions)[1]. We only validate the max length. If text is truly free form then you don't need to validate or white list anything. Just make sure it's valid UTF-8 (or whatever encoding you're using) and escape it when you display it . That combined with using prepared statements with bind variables (aka named parameters)…
Just to be a bit pedantic, unfortunately you don't get "proper i18n support" just by putting everything in UTF-8. Unicode lets you represent lots of abstract characters, from different languages and societies, in one character set. That doesn't quite tell you how to render the characters. For that, you need to know what language the text is in. Unicode wants you to provide that information out-of-band, e.g. in an HTM…
You probably need to know the language to do things like sorting, comparison, regex, etc. But if you're just storing and displaying user-entered strings and your software has no need to understand the meaning of the strings, I think it's enough to do what the parent says.
As long as we're playing the "Falsehoods Programmers Believe About Names" game again, here's the relevant patio11 article: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... If you try to validate names, or if you don't safely escape names along with your other user-input strings, you're gonna have a bad time.
In our app we neither validate nor escape user strings for any free form text (eg. "names" and descriptions)[1]. We only validate the max length. If text is truly free form then you don't need to validate or white list anything. Just make sure it's valid UTF-8 (or whatever encoding you're using) and escape it when you display it . That combined with using prepared statements with bind variables (aka named parameters)…
I've lately been coming around to the belief that anyone who uses the term "sanitize" in this domain, as in, "sanitize user input" really doesn't know what they are talking about (at least on average). The approach you describe is the generally correct approach; you need to ensure that the proper levels of escaping are being applied. Unfortunately this is nontrivial in practice, but it's still the correct solution.
The "sanitization" meme has resulted in me smacking down at least 3 commits from developers in my organization trying to "solve" XSS by scrubbing out all less than characters across all input from the user, or eliminating all quotes, apostrophes, less than, greater than, backticks (for shell interpolation problems), etc etc. Unfortunately, the problem is, these are in general all perfectly valid input values, and some of them really smack you in the face immediately. (For instance, names may contain apostrophes. You can't "sanitize" them away; you need to write your SQL layer to handle that correctly, such as with binding.) You handle them by managing your encoding layers correctly, not by "sanitizing" them.
(There's still some sanitization components in the resulting solution, I just don't think they are the way you should think about it. For instance, there are some characters that are flat-out forbidden in, say, an HTML attribute, and the right thing to do is just strip them out of any incoming string. But that should be thought of as a "sanitization" step being a importent element of proper encoding, but not the actual "answer".)
Why would null be confused with "null"? It shouldn't be a problem.
It's a SOAP request going from a flash client to a coldfusion server. Yeah.
For example:
Null - element equal to "Null"
- empty element (can also have a nil attribute set to true).
Earlier quoted context omitted.
Python makes a distinction between types, but it has a concept of falsyness (as do many languages, though it is often more restricted e.g. in Ruby only false and nil are falsy IIRC). Falsyness is used in boolean-ish contexts (if, while and explicit boolean conversion), by default all of None (null), False, 0, 0.0, "" (the empty string, unicode or binary) and empty collections ([], (), {}, set()) are falsy and althoug…
GForth uses 0 for 'false' but -1 for 'true'... that confuses me a lot.
"WSDL (SOAP) from AS3 to ColdFusion web service" I know it probably wasn't this guy's choice, but whooo boy.
For all that is wrong with flash as a platform, I have always found Actionscript 3 to be a far better structured and easy to work with language, compared to something like javascript, which has a very 'organic' structure. I can't speak much to ColdFusion or WSDL though.
Of course since Adobe has all but abandoned the platform, it probably won't be much of an issue in the future... Kind of a shame, as Flex was actually pretty nice. If adobe was more open with the flash client as a platform, and focused on the tooling (where they make their money), it could have been integrated into browsers, and had a much better chance of sticking around.