Could someone help me refute these claims, or, if they're true, can you help
me describe how to protect against them?
A few quick pointers.
Ruby strings are based on 8 bit characters. While there are a variety of UTF-8 libraries for Ruby,
basic methods like 'length' return the number of bytes, not characters, in a string
With Rails 1.2, you can do my_utf8_string.chars.length and get the
proper length. Same with truncate, first, and other character level
manipulations. So now you can easily manipulate UTF-8 in addition to
the fact that you've always been able to easily store and present
UTF-8.
Finally, the Ruby interpreter runs on Green Threads, so it can't make use of more than 1 CPU
on the new wave of SMP machines
With Rails, you run everything on processes, so this is a non-issue for
scaling a web application. The Shared Nothing approach is widely
regarded with excellent scaling properties, which the poster of this
also owns up to. And you get to scrap the pain and bugs of dealing with
threads.
It is almost entirely defined around the concept that a web page request translates into a
database query/update and the resultant display. This is true in the simple case.
I have no idea what this means and he does nothing to offer an
explanation for it. I think he's trying to say that Rails is primarily
for database-backed web applications. I'd agree with that.
...each page must be protected either with code in the controller
Where else should protection happen? The controller is exactly the stop
where requests are coming in and being handled. It's the obvious spot
to deal with access control. And we do. Additionally, we don't believe
that any one access control scheme fits all, so there's no default
access control in Rails. That's considered a feature, not a bug.
Objects pulled from the database must each be checked to see if they belong to the
user that is accessing them
But of course. Any access control would check whether the user has
access to the content. That's the nature and purpose of access control.
Rails makes this dead easy with patterns like:
@current_user.tasks.find(params[:id]
Which restricts task-finding to those tasks that are available to only
the current user. Pretty simple idea, which is both transparent, easy,
and very secure.
Further, the Rails methodology of including database primary keys as part of the URL
perpetuates the issue because it's very easy to change the ID in the URL and see data
that belongs to others
Keh? Again, you should of course make sure that private records are
only accessible to the current user. The URL is not really part of that
equation. And it's done as simple as the example above.
[ Only user id in session ]. This means that making multi-step processes (e.g., checking out of
a store, managing a shopping cart) is very difficult and prone to failure.
First, that's a pattern of best practice, not a programming constraint.
If you want to keep more stuff in the session, go ahead. But it's
usually easier to scale and easier to maintain when you don't do that.
There are plenty of patterns for storing shopping carts in the database
that work very well.
COMET style web app development is very, very difficult
Continuously updating a page? Rich Killmer and I (mostly him) flicked
together a proof of concept for this at Etech during a COMET
presentation. I've demoed this a few times at conferences, but never
needed it for real, so it didn't move much. Sufficient to say, it was
not "very, very difficult". (Again, this is FUDing big time as he
offers no evidence, or even argument, as to why that should be so).
Rails also has a bunch of security vulnerabilities...
He goes on to mention 1 issue. One does not many make. And even if
there undoubtedly have been more, and will be more, this statement is
meaningless without context. He says he comes from Java. Has there
never been a security issue with Java or any of the frameworks in that
language? (Yes, just like any other language and framework).
This means that an attacker can change the primary key of an object by
appending ?foo_id=44 to a web post and voila, the object has a new primary key
No, it doesn't. Primary keys can't be set by bulk assignment. And any
other attribute you wish should remain protected from bulk assignment
can easily be done so through attr_protected (see
ActiveRecord::Base).
(His example seems to confuse foreign and primary keys as well, so it's
pretty obvious he's out of depth.)
And even if you didn't know about that feature, you could still do as
you would in any framework that didn't do bulk-assignment. Just assign
by hand one-by-one.
There are other lurking vulnerabilities as well. But at this point in time,
Rails is as insecure as PHP was 5 years ago.
FUD-mongering at its best. Point to 1 incident, wave your hands about a
feature you didn't understand, and then allure to other mysterious
vulnerabilities.
For any application requiring complex user interaction or multiple user interaction,
Rails is not the best solution
Any assignment of medal is void without a definition of "best". Suffice
to say, lots of applications on Rails could be described under those
two labels. But whatever.
All that being said, Seaside is cool. I encourage you to check it out.
But hardly because of this "evaluation".
