If you're using Rails 5 ActionCable and you're not on Passenger, I would recommend upgrading to this release as soon as possible. Phusion[0] and other Rails 5 users[1] found a slow client issue with its implementation that was not protected against by the default app server Puma.
We contacted the Rails team early on about this issue and worked closely with them to have this issue solved. Now that 5.0.1 is released we are at liberty to disclose details about this security issue.
I've written a blog post[2] on the problem, using OS X network shaping tools and a simple app to demonstrate it. Rails apps running on Passenger were never affected as Passenger implements response buffering for regular requests as well as websockets connections. Note that even popular reverse proxies like Nginx don't perform response buffering for websockets as far as I know, so this is something to be aware of if you're running on other frameworks than Rails as well.
Approximately hundreds of small bug fixes, across much of Rails. The fixes include some important ones for database types, time comparisons, thread issues, record reloading, etc.
IMHO these fixes address dozens of bugs that could cause major puzzlement for a typical Rails developer.
Thanks to all the contributors for excellent work on this release.
> IMHO these fixes address dozens of bugs that could cause major puzzlement for a typical Rails developer.
That has been the reason I always avoid huge frameworks like RoR.
If I was to hit a bug like this, I wouldn't know where to start debugging. How do people deal with obscure bugs in the framework with something like RoR?
Then you share the test case in a bug report, and collaborate to fix it. Fixing it usually involves a source code dive.
With Rails's reasonably well documented and reasonably well written codebase it's usually possible to grok the source and dependencies even coming to it cold. With the possible exception of arel.
Ruby's dirty tricks department (monkey-patching third-party objects) and duck typing together are a real boon to debugging.
This is a correct reading of my remark. I happen to agree with the opinion of the followup as well, monkey-patching in production is a code stench.
Still I plead guilty to having occasionally monkey-patched prod code out of urgent necessity. My recommendation is to view it like an advanced and undesirable form of configuration; for my rails apps, each such hack always goes in an initializer file named for the library it is patching. If you are replacing third-party methods (or undermining the behaviour of a third-party method) and those methods are not called very frequently then judicious use of log noise e.g. through the deprecation mechanism will help at debug time.
Once you understand how it all works, I'll grant that that can take years, it doesn't take much time at all to debug upstream code. Just last night I was playing around with the jsonapi-resources gem, and found an issue that was keeping me from being able to dynamically generate resources. After realizing I couldn't work around the issue through more metaprogramming, I set about monkey-patching the code.
It got too late so I couldn't finish the job, but once I do, I'll get it working for my project, then package it up and make a pull request so I don't have to support it myself.
Ruby is definitely wizardry but it's accessible wizardry.
If you are lucky enough to hit it during development or testing, then yes, fair point.
If you hit however in production and only under load or some corner cases, it must be a real bitch to try to debug code that you haven't wrote yourself.
But since my original post is being seen as a troll, I think I will just shut-up and go hide under a rock or something. :D
> A few weeks later I have forgotten the specifics about my own code as well.
> Also: often there are fewer bugs in library code.
> And: getting help (paid or through stackoverflow) is probably easier.
I can definitely see your point, especially about being easier to get help. I imagine if you are anything other than a one man shop, you will be in much better position debugging Rails or Django, rather than trying to figure out the mess you ex-employee left.
Finding bugs for something you wrote yourself is easy because you WROTE it and can easily reason about what each method does, what data/methods does it have access to etc. etc.
Anyways, I unfortunately work with Rails and I hate it. To me Rails stresses and encourages bad practices, everything has an implicit environment inherited from a massive hierarchy of classes with their own implicit environment that will only work if the current state of the app matches what each classes assumes it will be.
Data changes and morphs during the initialization and creation of class instances causing shitty bugs. EVERYTHING needs careful consideration of all of these relations and class hierarchies before writing simple things.
Everything is highly coupled and interwoven making a change one place break something somewhere else. Rails should be taught in Universities as a case study in the pitfalls of Object Oriented Design
Also essentially all of the major players have left and moved on to new things. Most Ruby Gems haven't been updated in years!
Appreciating the sentiment, I would like to add that a great framework builds a great community around itself, which helps (A LOT) sort out (in the worst case work around) all sorts of issues. And this holds for Rails.
These are bugs from the 5.0.0 release. I can't really think of a time where Rails itself cause issues in my day-to-day (other than missing a timezone which was something I could easily fix).
One of the best (or worst) bugs fixed was the aborted transaction for PGsql. I am pretty sure hundreds of Rails developers are battling it every day and don't understand where it's coming from.
Even if you don't upgrade, this is something you should backport using a monkeypatch.
Can you explain more what you saw? What fails, and how does it fail? Does it raise an exception and the transaction undoes all queries, or does a query 'half execute' and save a dirty state to the DB?
If anyone's been holding off on upgrading to 5.x because of the deprecation warnings you get about requiring `params` as w keyword argument in keyword tests, I wrote a gem that could help: https://github.com/tjgrathwell/rails5-spec-converter
Are there other gems and resources available for accelerating the migration from 4 to 5? Been thinking about doing it for a project for a little while.
Slightly off-topic: is learning Rails still a good career choice? I'm not particularly keen on JavaScript on the server and I think I am slightly tired using .NET on a daily basis.
It's worked out well for me. I started picking it up almost 2 years ago and I make more than I ever did before. Where I work we are always advertising for Senior Rails Devs.
There are plenty of stable companies out there running Rails apps and I'd venture a guess that a lot of start-ups probably still use it as it's great for small teams and rapid-prototyping.
On a side note, we also have hired devs who don't have Ruby experience but who are generally smart, experienced people, who know more than one programming language and are willing to learn whatever stack they need to for getting the job done.
In Bangkok the demand for Rails developers is as strong as ever. With enough experience you will have no problem finding a job that pays better than other stacks. There are a number of companies like ours that'd be happy to help you with visa if you're willing to relocate. Happy to answer any questions! (contact info under my profile)
Serving the SHA-1 hashes over an HTTP connection doesn't really seem useful at all to me. If you're worried about MITM the hashes could easily be changed as well.
Not really. Depends completely on what you need. Not integrating with your existing asset pipeline isn't necessarily a plus depending on what your goals are.
There's also a weird amount of self promotion going on with that repo. Not sure what it is about that but it's kind of been a turn off to me.
We contacted the Rails team early on about this issue and worked closely with them to have this issue solved. Now that 5.0.1 is released we are at liberty to disclose details about this security issue.
I've written a blog post[2] on the problem, using OS X network shaping tools and a simple app to demonstrate it. Rails apps running on Passenger were never affected as Passenger implements response buffering for regular requests as well as websockets connections. Note that even popular reverse proxies like Nginx don't perform response buffering for websockets as far as I know, so this is something to be aware of if you're running on other frameworks than Rails as well.
[0] GH merge of patch: https://github.com/rails/rails/pull/26646
[1] GH related issue: https://github.com/rails/rails/issues/26409
[2] Blog post: https://blog.phusion.nl/2016/12/21/actioncable-under-stress-...