In a previous job, I used a technique like this to deploy pretty big Oracle application, being worked on by 160 developers, so using migrations to manage your database does work... with some care!
393 karma · joined October 22, 2007
In a previous job, I used a technique like this to deploy pretty big Oracle application, being worked on by 160 developers, so using migrations to manage your database does work... with some care!
How do you get 'outdoor maps' into the App, ie do you license them or are they available freely somewhere?
What is the best idea then? If you bind variables to SQL statements, you are SQL injection safe 100% of the time. There is no crafty input sequence that can fool anything.
> In most cases where you want a prepared statement, you'd be better off using a stored proc, as you'll skip the expensive optimization every single time.
I am only qualified to speak about Oracle which is a DB I know extremely well. A query is a query, whether it comes from Java, Perl, Ruby or inside of a stored proc. If you prepare a statement once, and then cache that handle and execute it many times, you optimize the query one time. Also in Oracle, if you prepare-bind-execute one time only, the next time you do the same sequence of steps you Oracle doesn't have to optimize the query again - it can spot it is the same as a previous query and short circuit the process.
Mysql I think doesn't cache SQL statements for later reuse like Oracle, which is why binding isn't as important for performance (in Oracle, not bind queries is a pretty good way to bring the database to its knees) - but its still essential for security.
> SQL injections are 100% avoided by user input control in the application, and the simplest way is to escape all escape characters
What this bug has just proven, is that this escaping is not all that easy - crafty attackers can come up will all sorts of strings that seem to work around the escaping time and time again.
>Impacted code directly passes request params to the `where` method of an ActiveRecord class like this: Post.where(:id => params[:id]).all >An attacker can make a request that causes `params[:id]` to return a specially crafted hash that will cause the WHERE clause of the SQL statement to query an arbitrary table with some value.
For me that is a classic SQL injection attack that can be avoided 100% of the time if you use bind variables for all user input into an SQL query.
Rails doesn't use bind variables - it uses something that looks similar, but it is actually rails code that escapes and concatenates the user input into the query string before executing it. This bug was in that escaping code. However, if Rails correctly bound the inputs to all queries (which is pretty easy to do) then this escaping code could be removed totally and this problem would never have appeared.
Then there is performance - in Oracle bind variables are essential for scalability. I read somewhere that Mysql performs better without bind variables.
For most databases by caching prepared statement handles and binding / executing that handle many times, it will perform better than handling many one off queries. I have benchmarked a 20% improvement in throughput on Oracle by making just that change (which is a one liner in the JDBC driver).
Where I live, in winter, without daylight saving it would be dark until 9.30am or after in the mornings, meaning all the kids need to go to school in the dark, which is more dangerous.
Then at the peak of summer, it would probably still be daylight until close to midnight.
The closer you are to the equator, the less swing there is between the number of hours of daylight between summer and winter. Even between the very north of the UK and the very south there is an appreciable difference.
Way back, I found I had two problems - if I was doing something that did a lot of uploading (eg seeding a torrent), my download speed would tank because the tcp/ip packets were bogged down in the upload queue.
I also like to be able to ssh into my machine while away from home, and if I did that while uploads were going on, the ssh terminal was basically unusable.
Back then I discovered tc - it was able to make TCP control packets (ack's etc) and ssh related packets jump to the head of the queue, and the other upload stuff have a lower priority.
Looking back at the script I created now, I don't really understand what it is doing, but it remember it worked. I still run it today and just take it for granted.
I tested it by start a large upload while ssh'ed into the box from the internet - I turned off the tc rules and the terminal became unusably laggy, and then I turned the rules on and it worked perfectly.
I set myself a target of writing one good blog post a week about a year ago, with the target of having 52 posts in a year. Right now, I have about 31 with 1 month to go - I am pretty pleased with that, especially since I have been on at least 4 weeks holidays through the year where I left my laptop firmly at home.
As an aside, I did run across a bug, not performance related, but a case around popen where JRuby doesn't behave the same as MRI - I raised a ticket (JRUBY-6225) but it doesn't seem to be getting any traction. I understand there are probably plenty of tickets to be prioritized, but this one is a bit of a show stopper for me. If anyone from the JRuby team is see this and has time to have a look at it I would be grateful.
edit - I tried this out and right now cannot get that error, so not sure where I got that idea from.
I only ever played with it, but it seemed like a great piece of work, and was all coded in Smalltalk (Seaside).
I cannot vote this up enough. Also, depending on what database you are using (eg Oracle) if you don't use prepared statements (aka bind variables) you are guarantee killing your DB performance.
People have argued with me in the past that for things like sorting the data they cannot use bind variables. In that case, use the user input to select which safe string to use, eg:
if user_select_sort == 'by_account_num'
return 'order by account_num asc'
elsif user_select_sort == 'by_transaction_date'
return 'order by transaction_date'
else
return ''
end if
Then if someone sends in something tricky, it will just order wrong.For me, the only advantages of stored Procs over straight SQL (generate or hand coded) are:
* Security - you can revoke rights to directly access / change the tables from the app layer, making all access be through procs. However, in general you can probably create a similar security setup using views.
* Many SQL calls that need to be run as a set to give a single answer - this avoids the round trip latency of firing many SQL calls from the application.
I'd am genuinely interested to hear of more advantages.