does threadsafe and ruby 2.0 mean we can create multiple instances with something like unicorn without forking the entire codebase?
Ruby 2.0 means less memory usage with unicorn since the GC in Ruby 2.0 is copy on write friendly.
Ruby on Rails 4.0.0.beta1 released
61–70 of 91 posts
Re: Ruby on Rails 4.0.0.beta1 released
#62Earlier quoted context omitted.
The examples here do not include SQL injection from known CVEs and are not vulnerabilites themselves, only potential misuses of the methods. What would you like to have changed here? The methods work fine as long as you do not explicitly embed a user-supplied string in a larger SQL fragment.
I don't think all of these examples involve embedding strings. Many people assume that they can use any ActiveRecord method, and as long as they don't embed strings, they'll be safe from sqli. Take this first example: Order.calculate(:sum, params[:column]) I've just checked in Rails 3.2.12 and this is still possible, haven't checked against Rails 4.0. If I pass in: http://localhost:3000/adverts/1?column=id ) FROM use…
Ok, this one is a genuine problem in that the method is expected to only deal with column names and is not supposed to accept full SQL, but you made it sound like the page was a list of security issues that Rails should deal with but isn't, which on top of the recent discussions about Rails security sounds a lot like FUD (maybe unintentionally); this is actually a page listing Rails anti-patterns.
If you actually learn Rails and aren't just piecing things together until it works, it isn't a secret that most methods accept raw SQL as the first argument, with optional placeholders for expected values, so if you want escaping you either pass an array ["col1 = ?", params[:val1]] and the values will be quoted or you have to quote explicitly. Methods like .where(), .joins(), .having(), .order() etc. would be crippled if they escaped this first string argument so I am not sure how a "fix" should like here, you have to demarcate somehow which input is trusted and which is untrusted and those methods are 95% of the time used to deal with trusted input.
Re: Ruby on Rails 4.0.0.beta1 released
#63Is the web socket story substantially the same? In other words, Rails just isn't that great a platform for it?
I think Rails is great, but this is one area where it's not a good choice.
Re: Ruby on Rails 4.0.0.beta1 released
#64Earlier quoted context omitted.
I don't think all of these examples involve embedding strings. Many people assume that they can use any ActiveRecord method, and as long as they don't embed strings, they'll be safe from sqli. Take this first example: Order.calculate(:sum, params[:column]) I've just checked in Rails 3.2.12 and this is still possible, haven't checked against Rails 4.0. If I pass in: http://localhost:3000/adverts/1?column=id ) FROM use…
Ok, this one is a genuine problem in that the method is expected to only deal with column names and is not supposed to accept full SQL, but you made it sound like the page was a list of security issues that Rails should deal with but isn't, which on top of the recent discussions about Rails security sounds a lot like FUD (maybe unintentionally); this is actually a page listing Rails anti-patterns. If you actually lea…
If you actually learn Rails and aren't just piecing things together until it works
This kind of defensive attitude isn't helpful, I'm quite familiar with Rails since 1.x thanks and want to see it improve, particularly on security issues. I use it every day. I've only quickly looked at this page but as it contains many common antipatterns, and some straight up vulnerabilities, I think it'd be worth fixing everything on it if possible. Having read the above list I'm starting to think I'd be best to convert all params explicitly to the expected type before use, as Rails accepts many varying types for params and this has increased the attack surface. I'm actually pleased there is a spotlight on Rails security right now though as things will improve - much better than no-one but blackhats being interested.
I highlighted two vulns from the list, one in Model.exists? which is expected to take an id param straight from user input, and one in Model.sum,count etc which is more serious but less likely to be encountered as it requires using a column name straight from user input (not advisable). Neither of them take sql as the first argument, one is intended to be an id, and the second a column name. While the above example is a misuse of sum in my opinion, I think Rails should still be a good citizen and deal with it, given the common pattern of Model.query(params[:xxx]) which can be very useful and which many people will pattern their other usage on - any method which takes params directly and not raw sql (i.e. not the ones you list) should I feel be protected against sqli, even or especially if it is not a commonly used one.
Taking security seriously (even if it means inconvenience or working around common user errors) is not FUD, it's a worthwhile process and one which Rails should continue with.
Re: Ruby on Rails 4.0.0.beta1 released
#65Earlier quoted context omitted.
Ok, this one is a genuine problem in that the method is expected to only deal with column names and is not supposed to accept full SQL, but you made it sound like the page was a list of security issues that Rails should deal with but isn't, which on top of the recent discussions about Rails security sounds a lot like FUD (maybe unintentionally); this is actually a page listing Rails anti-patterns. If you actually lea…
If you actually learn Rails and aren't just piecing things together until it works This kind of defensive attitude isn't helpful, I'm quite familiar with Rails since 1.x thanks and want to see it improve, particularly on security issues. I use it every day. I've only quickly looked at this page but as it contains many common antipatterns, and some straight up vulnerabilities, I think it'd be worth fixing everything o…
I just think that with your first brief comment you unintentionally scared a lot of people away from Rails, possibly indicating a new release was done but some serious security issues were simply ignored. I had trouble understanding what you meant until you supplied those additional explanations, many thanks for which. I agree the examples you pointed out are problematic, I am just happy we made clear that this is just about 2 or 3 examples from the long list in the link you posted. There is certainly room for improvement in Rails security-wise and I am also happy this is being discussed, as long as the discussion is balanced.
Re: Ruby on Rails 4.0.0.beta1 released
#66How well does rails 4 play with mongoid? Any breaking changes I should be aware of?
This question would be better addressed to the Mongoid team, but it looks like they're working on it. I would expect an announcement when they consider it stable enough for production.
Re: Ruby on Rails 4.0.0.beta1 released
#67Hello everyone! I am MEGA EXCITED for this release, as it's the first version in which I'm a committer. Wooo! In addition, 954 other intrepid Rubyists in total contributed to this release: http://contributors.rubyonrails.org/edge/contributors Please note that this is a beta, not an rc, so some things may be a bit wonky. Please file an issue on GitHub and I will do everything I can to help you help us iron out all the…
I'm curious to know if these examples of potential SQL injection tested against 3.2.11 have been dealt with in 4.0? Would be great to see these possible problems tidied up. http://rails-sqli.org/
Rather dangerous stuff. I didn't know ActiveRecord would allow to shot yourself in the foot.
Re: Ruby on Rails 4.0.0.beta1 released
#68What is the "Rails way" of doing AJAX calls and updating the DOM? I've been embedding Backbone views in the parts of my app that are the most interactive, but I feel like there's gotta be a better way.
It just so happens that one of my major contributions to this release was writing a 'working with JavaScript in Rails' guide: http://edgeguides.rubyonrails.org/working_with_javascript_in... Others mentioned Turbolinks, but they forgot about remote_form_for and friends. If you _are_ building a full JavaScript application, Ember.js works really well with Rails + ActiveModel::Serializers. There might be some rough patch…
Just want to chime in and say how fantastically ActiveModel::Serializers and the Ember.js REST adapter work together. I built a project with them over the weekend and the experience was overwhelmingly frictionless to a degree I hadn't experienced doing this kind of thing in the past.
Re: Ruby on Rails 4.0.0.beta1 released
#69Earlier quoted context omitted.
If you actually learn Rails and aren't just piecing things together until it works This kind of defensive attitude isn't helpful, I'm quite familiar with Rails since 1.x thanks and want to see it improve, particularly on security issues. I use it every day. I've only quickly looked at this page but as it contains many common antipatterns, and some straight up vulnerabilities, I think it'd be worth fixing everything o…
I just think that with your first brief comment you unintentionally scared a lot of people away from Rails, possibly indicating a new release was done but some serious security issues were simply ignored. I had trouble understanding what you meant until you supplied those additional explanations, many thanks for which. I agree the examples you pointed out are problematic, I am just happy we made clear that this is ju…
I don't think he scared anyone away from Rails. Rails is not hurting for popularity in any way.
Re: Ruby on Rails 4.0.0.beta1 released
#70Earlier quoted context omitted.
For traditional web pages does it ever make sense to use Backbone/Ember/etc? I've used Backbone on one project and I kind of like the MVC aspect for some things but the thing I'm working on right now is more of a traditional web app. There are some interactive forms where it kind of makes sense to have a model and a view that reacts to changes in the model, but in the end the form is POSTing to a standard rails contr…
In the recent discussions about Discourse, it was said that on slower connections, it feels way snappier than a server-side solution would be. Frankly, I'm a server-side guy, so I prefer that kind of development, but there are advantages to SPAs, and like any good engineer, you should use the right tool for the job. Rails is modular enough that you can do whatever you want, Turbolinks is just a gem, so if you don't w…
I agree. I would love to see some article on What TurboLinks actually breaks and How to avoid it. As much as the world love JS and Client Side Rendering. My Experience is that most of these people are either designing it with Chrome in Mind ( And hell yes they are ) or People using other browsers with a single tab at a time. ( Tell me if any single developer test their website in a Multi Tab environment )
Having JS heavy web page will slow down the browsers. That even includes Chrome, you just need a larger number of tabs. On Firefox a few JS heavy site with a slow computer will make your site experience sucks.
Although not a single user would blame the site ( It is always the browsers' fault. ) but to me, most of the time, the less JS the better.
Discourse is pretty fast, but to say 300K zipped JS file is peanuts just doesn't cut it for me ( How about 100K? That is peanuts. ) And again, slow JS execution and loading is something i have zero control of.