Slashdot Mirror

On the surface, JS is a really nice language, but it really has a fair share of warts which will bite you. And yes, I'm aware that Javascript is neither DOM nor CSS. For those interested, Bob Ippolito (the author of MochiKit) wrote the best "Javascript sucks" article I've ever read.

You're likely referring to the JavaScript Hijacking paper from Fortify Software, the one which finds a loophole in a ridiculously contrived scenario that applies to roughly six sites on the planet. The threat they identify is real, but unlikely; it's orders of magnitude less severe than an XSS flaw or SQL-injection attack. Bob Ippolito demystifies the threat.

Nine times out of ten, a security exploit that uses JavaScript as the attack vector must be solved on the server-side, not in the JavaScript itself. This isn't buck-passing; it's just the truth. Nothing I can add to a JavaScript library will intercept a XSS attack, since the vulnerability (unsanitized HTML) lies on the server. Once the malicious JavaScript is on the page, the game is over.

That said: one of the suggested ways to protect yourself from this hijacking flaw is to surround the returned JSON with comment delimiters. Prototype 1.5.1, released on Tuesday, can handle this automatically.

(Disclosure: I'm a member of Prototype Core.)

There has been push back on some Ajax vulnerabilities:

http://bob.pythonmac.org/archives/2007/04/05/forti fy-javascript-hijacking-fud/

but that might not be the particular vulnerability that you are talking about(none of which makes whitelisting any less effective, but the immediate value may not be so high).

A mac port of pygame is available here: http://pythonmac.org/packages/py24-fat/
It uses some form of wrapper program for the SDL surface so it doesn't need X11... Take a look.

For windows, I use py2exe and have a custom script that makes an innosetup install file. If you are interested, I can dig up this script for you (I think it should actually be a distutils setup, that would be nice) however, they are trivial to make.

For OSX I use BundleBuilder which generates mac bundles and is really, really nice especially since OSX comes with python pre-installed. I even use this script to create non-python bundles.

For linux I use PyInstalelr and tarballs :) There is really no good consistent linux installer, but I have had some success with PyInstaller.

The fact that PHP and MySQL are the most deployed tools for web development is a rather sorry situation, given the deep shortcomings of both tools.

See these articles about the many PHP warts:

Experiences of Using PHP in Large Websites

Why PHP sucks

The PHP Ghetto

You will be happier with a more mature and complete dynamic language like Python, or even (gasp ;-) ) Ruby.

Similarly, see these other articles about the many MySQL warts:

MySQL Hate

MySQL Gotchas

Compare the last one with the one for PostgreSQL:

PostgreSQL Gotchas

Finally, an in-depth comparison between MySQL and PostgreSQL on Slashdot itself:

Comparing MySQL and PostgreSQL 2

Finally, recall that both MySQL's transactional backends are now controlled by Oracle:

Oracle Acquires Sleepycat

Avoid both PHP and MySQL as much as you can, I say. There's better stuff out there.

Here's an article from James Mc Parlane's Blog that describes the horrible problem with prototype.js and its ilk that define methods in Object.prototype and Array.prototype.

-Don

James Mc Parlane's Blog

Why I Don't Use The prototype.js JavaScript Library

When it comes to JavaScript there is one issue for which there seems to be two polarised camps, and that is the question of extending the inbuilt JavaScript Array and Object types via the prototype object. There are those who do, and those who don't.

I am most definitely one of those in the "Don't, because it 'would be bad'" camp.

Now, thanks to the Web2.0/Ruby On Rails/Nuevo Bubble phenomena there is a widely used library that makes great use of the prototype object and that is Sam Stephenson's prototype.js library.

I ran into an issue 6 months ago and decided I would never ever use prototype.js, despite the fact, and I don't say this often, that after an examination of the code, prototype.js is an inspired work of art.

What I and many many others have discovered is that using the prototype object on the Array and Object inbuilt types increases the chances that your code will conflict with existing or external code. It makes your code not play well with others, so once you start using prototype.js, you have to keep using prototype's paradigm because by extending Array and Object via the prototype object it secretly modifies some of JavaScripts default behavior.

It's the crack cocaine of JavaScript.

This can be a good thing. If you don't want to waste time writing your own JavaScript libraries and learning how everything really works, then using prototype.js and the libraries that extend it (e.g. Open Rico) is a very good way of developing. You will save time and money and all you need to learn is "the way of prototype.js".

Now the entire tasty raisin for the MetaWrap JavaScript libraries is to allow others to easily remix MetaWrap applications via a client side API that can be invoked via XML. The result is that CSS, HTML and JavaScript can be injected into the application, or XML and HTML at any point in the rendering pipeline of the application.

So I simply had to reject prototype.js because, out of the box, the very first time I tried to use it - it snuck out and cut the throat of the JavaScript I was using that relied on performing a for(x in object) on the contents of an Array.

In JavaScript, value types are subdivided into primitives and objects. Objects are entities that have an identity (they are only equal to themselves) and that map primitive properties to other value types, ("slots" in prototype-based programming terminology) - see these testcase #5 - #7. Because of this behavior JavaScript objects are often mistakenly described as associative arrays or hash tables, while functionally they behave like an associative array/hash table, technically this is not their true nature.

Despite this the JavaScript programming world has come to rely on these objects behaving as predictable associative array/hash tables - and prototype.js breaks this.

There is no object more galactically useful than a good associative array/hashtable. There is no problem that can't be solved with a large enough hash table. In highly granular interpreted languages like JavaScript it provides a way to dip into pure native brute force computing power mostly unhindered by the language interpreter.

I just finished reading an interesting comparison of Java, PHP and Python over on Bob Ippolito's weblog. It talks about the implementation of a simple web service in the three languages. To summarise:

• 117 lines of very liberally spaced Python code, or
• 138 lines of insecure PHP code, or
• 3004 lines of Java code in 45 files, 29 lines of SQL, and 246 lines of XML configuration in five files.

That's to implement the same web service.

Most of this stuff is common knowledge, but here are a few links I was able to dig up:

Wikipedia Criticisms (with sources)

Comprehensive list of MySQL "gotchas"

Interesting Blog Entry

Google should be able to provide more info on MySQL's problems. It's getting better, but I still trust my data to PostgreSQL.

To me it seems like a silly exercise to replicate rails in python or what have you.

1. TurboGears is not a Rails clone.
2. Most parts of TurboGears existed before Rails: CherryPy, SQLObject, FormEncode (and Python of course).
3. Kid is most closely related to Zope Page Templates (from the Python world), not anything from Rails.
4. MochiKit has a certain relationship to Prototype (the Javascript library from Rails), and is compatible with it. However, it's not that the author particularly likes Prototype.

Rails has taught us some important lessons, but they aren't really technical lessons:

1. We shouldn't sit around and say "oh, those poor people using PHP/Java/etc, too bad they don't know about what you can do using X". Instead we should talk more loudly and insistently about the advantages of our platforms. If you do it right people will pay attention.
2. We haven't concentrated enough on full-stack integration. We've been overvaluing decoupled pick-and-choose components. Full-stack integration doesn't have to mean coupling -- it can just be a matter of presentation, and making sure tools are complimentary. Not all of the Python frameworks are coming at it from this direction, but TurboGears very much is.
3. Things like screencasts are nice.

After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.

As for Ruby: I think the two languages are largely equivalent in terms of what you can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.

And this, via a comment in your link, is a cool example of what can be done in OS X because Objective C is a late-binding dynamic language: it's a third-party fix that works by overriding a method a run time to add a check for suspicious domain names.

There's a scripting component for Python called OSA Python, and one for Javascript called Javascript OSA.

Frontier's UserTalk language is another implementation.