
Running GitHub on Rails 6.0 - edmorley
https://github.blog/2019-09-09-running-github-on-rails-6-0/
======
juliendc
I've a bunch of small Rails apps running on Heroku and I've to say that I'm
impressed by the relevance of the new features in the latest Rails releases.
Action Text, Active Storage and Action Cable are solving common and painful
issues in any web app.

I've recently built a web app with Node and the time we spent solving problems
which have already been solved a thousand times is astonishing. Things like
picking an ORM, having a proper database migration system, running a test
suite. It's actually quite depressing when you come from Rails where
everything is working coherently out of the box.

The fact that there is no standards in the Node ecosystem make it a bit more
painful. You have to carefully choose between many different libraries to
solve your problem. Some of them are in TypeScript, other still use callbacks,
etc. We basically had to glue together many libraries to get something
working. All those hours could have been spent building the actual product and
delivering value to our customers.

Hope they will ship many more releases!

~~~
freehunter
I've been trying to use NodeJS after using Rails for years and it's just such
a terrible experience. I don't want to install every basic package by hand and
generate every model and view and controller by hand. This is basic
boilerplate nonsense that made Rails so popular 15 years ago, and NodeJS
throws away every lesson we learned from Rails.

React is okay as a front-end but without a full stack framework, the current
state of Javascript is like stepping back into 20 year old PHP development,
where everyone just hacks together anything they can find with no structure,
no convention, and no security.

~~~
tekkk
Like others have mentioned, this is an apple vs orange comparison. Ruby &
Rails is not the same as NodeJS. A popular framework which you probably used
with NodeJS is Express, that as its documentation states tries to be a minimal
framework for creating NodeJS servers. I agree that something like Rails has
its own benefits, but I can't really take seriously this type of complaining
when it's directed at the wrong thing. You're complaining about _frameworks_ ,
not _NodeJS_ the runtime. And NodeJS is not fixed to some specific framework
that forces you to do things in one way. And thank god for that.

There was some initial burden I admit with NodeJS but I have at least got to
the productive plateau (with TypeScript). Once you figure out the pattern that
works for you, it gets simpler. The inventing part is what drives most
developers crazy, and it did for me too. It's perhaps too non-restrictive but
well, hopefully there's somebody in your company showing you the right way.
And you don't want to install every basic package by hand? But have them
already included? You understand that adds quite a bit of bloat to projects
that have no need for eg CORS or body-parser. And "code hacked together" is
only a problem with bad programmers, you can get working and secure code with
NodeJS, it just needs thought put into it. And yes, Rails has advantage with
this but I think you made that argument clear.

Instead of making the argument "NodeJS is bad" you should aim that at the
frameworks of NodeJS. SailJS was a good attempt at Rails but it's way too
restrictive with its patterns (and sadly the documentation is not good). Deno
looks promising and I hope people will be building better frameworks on top of
that.

~~~
danpalmer
I think the point is more that a Rails style framework does not exist in Node.
There are a few projects that have attempted to be like Rails, but none that
appear to have succeeded in any real way.

In the Ruby ecosystem, Rails will get you very far. In Python, Django will do
the same. PHP –> Laravel. Scala –> Play.

JS does not have an equivalent, and the community seems to actively dislike
the approach. That's fine, a monolithic framework approach isn't always the
best option, but in the Node ecosystem it's not even an option on the table.

~~~
tekkk
Well your argument is a lot more nuanced than the original comment I responded
to. And I agree, it is burdensome especially for people not familiar with
NodeJS that there isn't a one-size-fits-all framework. I don't really know the
main causes why it happened, but I guess people felt satisfied with Express &
Koa though it left, and still leaves, a lot for programmers to do by
themselves.

Perhaps because Express & Koa were "good enough" there never was a large
enough momentum behind say SailJS to make it work. Nevertheless my experience
with ORMs or scaffold generators has been that I always feel they are one
custom use case away from turning from time-savers to time-sinks. When you
write your own SQL and implement your own models/services or whatever
abstraction you decide to use, you get a much deeper understanding of what is
going on than just trusting your framework to do it for you. And is that good
or bad? That is certainly a topic for debate.

~~~
danpalmer
> Perhaps because Express & Koa were "good enough" there never was a large
> enough momentum behind say...

This is interesting to me, because Ruby has Sinatra (and others) that compare
well to Express/Koa. Python has Flask which is very popular, as well as a
number of fantastic alternatives. These ecosystems have very mature, well
designed, small web frameworks, but still people choose the larger frameworks
in these ecosystems, and all of the frameworks get good maintenance.

I wonder if it's a cultural thing in the JS ecosystem. Maybe the ease of
publishing a package creates a race to the bottom in terms of package scope,
which makes it so difficult to sustain larger more all-encompassing packages.

I've worked with Ruby+Rails/Sinatra/Cuba, Python+Flask/Django/Bottle/Sanic,
and Node+Express, and when I was in the Node ecosystem I sometimes really
wanted that Rails/Django equivalent – not always, but the lack of it would
cause me to avoid Node for large backend projects.

------
sellingwebsite
My comment on one of the previous discussions:

I don't want to start a flame war here, but I think Rails (and gem ecosystem
in general) is a better choice than Django, at least for SaaS apps.

These are all my personal opinions, take it with a grain of salt. Having said
that, here we go:

* Authentication - it is a pain if you'd like to deviate from the standard Django User model (using username to login instead of an email). I don't like Devise either.

* Asset pipeline, even though it is not updated anymore (sprockets) and partially replaced by the webpacker, is still better in Rails

* Configuration spread across multiple files, by environment, instead of a single config.py file

* Sidekiq has a better API compared to Celery. Also, Celery's default broker is RabbitMQ, not Redis. It is really hard to find managed RabbitMQ hosting, for Redis there are plenty

* Mailer previews, small but quite useful utility

* Better security by default: Rails comes pre-configured with a bunch of security headers[0].

* Testing - Minitest and Capybara is just a joy to work with.

* I prefer ActiveRecord over Django ORM

* Rails isn't afraid to deprecate _things_ and move forward. This isn't the case with Django, which is big on backwards compatibility. I don't like it, since it puts into a disadvantage folks who are starting new projects. Different strokes for different folks, I suppose

I could go on and on, but I remember struggling a lot with Django/Celery when
building a SaaS app. I decided to switch to Rails and haven't looked back
(Rails has its warts as well). YMMV

[0] [https://guides.rubyonrails.org/security.html#default-
headers](https://guides.rubyonrails.org/security.html#default-headers)

EDIT: Added last point about backwards compatibility

~~~
tyre
ActiveRecord is the best ORM I've ever used, in any language, and I don't know
of an engineer I've worked with who disagrees, regardless of their preferred
stack. Using `merge` on two queries still blows my mind. I've been using
SQLAlchemy lately and it's a daily reminder of just how many things AR got
right.

Rails has its downsides (helloooooo memory usage!) but for getting up and
running fast and having a full toolkit available to get the basics done, it's
a pretty amazing project.

~~~
pg_bot
I used to hold this opinion until I started using elixir's ecto library.
However, I still do hold ActiveRecord in high regard.

~~~
tyre
I love ecto as well. I love pure SQL and interfacing closer to raw data.
Phoenix/Ecto is where I'd gravitate starting a new project (we used it in
production at our startup) for many reasons including the simplicity of
deployments.

For people getting started with engineering, AR is a nice wrapping/mapping of
SQL => object oriented models. There's a mix of productivity, approachability,
and feature set that puts AR ahead, for me, as a general use ORM.

I would agree, though, with a strong and experienced engineering team Ecto and
Elixir are quite nice.

------
nickjj
Every time a Rails link appears on the home page it's filled with a bunch of
technical reasons on why Rails is good and then there's a bunch of posts about
how other frameworks might be better. These are healthy discussions IMO.

But I think a lot of people overlook that one of the main reasons why Rails is
so good / popular is that you get to see posts like the one we're looking at:
Running GitHub on Rails 6.0

There's not too many other frameworks where there's a really strong track
record of it running really popular sites (github, shopify, basecamp, airbnb).
Not only are they popular, but they are well done sites that are pretty tech
friendly. It just gives a sense of confidence that it will work for your small
/ large app and you don't get that with most other frameworks.

Knowing that billions of page views have been through the framework irons out
so many edge cases. Both bugs and performance issues, and you often get that
perk on day 1 when a new release is out because it's already been running on
basecamp for months (and maybe other big sites too).

I mean check out this quote from the article:

 _> GitHub engineers sent over 100 pull requests to Rails 6.0 to improve
documentation, fix bugs, add features, and speed up performance._

Combine that with the Rails approach of batteries included and you know that
the core of your app is in good hands. You can't really go too wrong by using
it along with a few well maintained gems.

~~~
k__
True.

dev.to runs on Rails too.

Currently I'm looking into AWS Amplify, which tries to be the Rails of
serverless. Building a serverless app as you would build a monolithic app
sounds intriguing to me.

------
lucisferre
Perhaps an unpopular take, but what is described in the first paragraph as
"smoother, easier and faster" than ever seems to refer to an upgrade process
that has been going on for over a year.

> As soon as we finished the Rails 5.2 upgrade last year, we started upgrading
> our application to Rails 6.0.

> Instead of waiting for the final release, we’d upgrade every week by pulling
> in the latest changes from Rails master and run all of our tests against
> that new version. This allowed us to find regressions quickly and
> early—often finding regressions in Rails master just hours after they were
> introduced. Upgrading weekly made it easy to find where these regressions
> were introduced since we were bisecting Rails with only a week’s worth of
> commits instead of more than a year of commits. Once our build for Rails 6.0
> was green, we’d merge the pull request to master, and all new code that went
> into GitHub would need to pass in Rails 5.2 and the newest master build of
> Rails.

Realistically how many hours of work went into this upgrade process then?

Edit: I should add I think it really is wonderful that Github contributed so
much to the new release and was so involved. I'm just not sure that it is
realistic or even ideal for the average Rails consumer to upgrade in this
manner.

~~~
AlchemistCamp
> how many hours of work went into this upgrade process then?

It's hard to say, but I generally agree with upgrading regularly instead of
waiting until you're so far behind that it's an ordeal.

~~~
atonse
Agreed. The problem happens with convincing your clients to pay you to do so.

I have a client that I've been telling for 2+ years to upgrade from Rails
4.2.3 (and Ember 2.8), but they only now funded it. So I'm having to do 3+
years of upgrades and it's a huge headache.

And at the end of it, if I've done my job correctly, the app will look
identical.

~~~
bdcravens
I would point clients to the Rails support policy, and have the same support
policy.

[https://guides.rubyonrails.org/maintenance_policy.html](https://guides.rubyonrails.org/maintenance_policy.html)

------
antimatter
It's been a long time since I've looked at Rails. Is there anything similar to
Railscasts (free or paid) but up to date with latest Rails features?

~~~
Hates_
GoRails ([https://gorails.com/](https://gorails.com/)) is probably the most
similar to Railscasts but which covers more up to date features.

------
adreamingsoul
I loved working with Ruby, and RoR. All my completed side projects used RoR.
Ironically, I do have a couple incomplete side projects that used NodeJS.

I never understood why RoR recieved so much hate in the tech community, or
from CTOs.

Glad to see a prominent service like Github continue to use RoR.

~~~
danmaz74
Every successful project is going to get hate from somebody; if anything else,
those who don't like some of the choices of said new successful project will
be worried to be forced into them, and some will react finding any possible
reason to stop the momentum.

------
IfOnlyYouKnew
Rails 6 really is a well-rounded update. It seems the new trend goes towards
"bare-bones" http servers, but I'm _insanely_ productive in a Rails app, even
if it's one I have not worked on before.

I've seen quite a lot of "Rails-hate" over the last view years, and it can
only be coming from people who never got to experience the world that was web
development before Rails: Every project had it's own, usually quite creative,
structure. There'd be configuration values in `config.inc.php`, but also in
`configuration.php3` and `config.old.inc`, and `index.php` and so on. Just by
establishing a standard folder structure, DHH probably made web devs
everywhere twice as productive.

I also think its reputation of being too restricting isn't entirely deserved.

As but one example: I often opt to use SQL instead of the canonical query
builder, especially for queries that do not return individual models but
aggregate values or the like. You can even mix-and-match to your liking, i. e.
writing individual clauses of the query (select/where/join/having/count) in
SQL and using the ORM for the others.

So here' to hoping for another 6 good releases at least!

~~~
_hardwaregeek
It's also interesting how people have gone backwards in terms of convention.
As far I know, there's no standard convention for JavaScript server layouts
(maybe server.js, but I've seen stuff in index.js or main.js). Likewise
there's no standard way to plug in servers like Rack. Or a standard ORM in the
JS world. I figured conventions would come with maturity but the JS world is
getting mature and yet there's not many conventions

~~~
baroffoos
I found this to be true when building a SPA. On rails I am already told the
best place to put things but on the JS side its just "do whatever you want" so
I try something and find out later that it wasn't a great way to do things so
I am just wasting my time working out the best way to organize a project. I
also have to deal with index files that just import every single component for
the frontend when on rails this kind of stuff is auto generated.

------
pizza234
I wish they would be so keen on migrating to MySQL 8.0 as well :-)

Their (amazing) tool Gh-ost is broken on MySQL 8.0, which suggests that
they're still based on 5.7.

It's a big issue for my company (and I guess for any mid-sized company), since
at mid-sized companies the schema is likely big enough to have slow
migrations, but not big enough to have fancy replication topologies. For such
cases, there's nothing like Gh-ost :-)

~~~
geerlingguy
So far I haven't seen many people switching to MySQL 8... almost every example
and app I've seen in the wild is on 5.6 or 5.7, or switched to MariaDB (or
more infrequently, Postgres).

~~~
pizza234
Well, if we put it this way, the same could be said of Rails 6. I understand
their plans of course, and that's why I expressed it as wish.

Regarding MariaDB or PostgreSQL, can you enumerate/detail the app you've seen
switching? Is it the, say, 1/2% area of all the projects? 5%?

Probably, in the low one-digit percentage, there are switches toward anything.
I'm somewhat skeptical any non-trivial projects undertaking this kind of
change. GitLab (to mention a large one) didn't really switch, as they were
supporting both.

~~~
qiqitori
When you install 'mysql'/'mysqld' in Debian or RHEL7+-based distros, you get
MariaDB... So staying with MySQL and not "switching" to MariaDB is a lot more
effort. (MariaDB is a fork of MySQL and the binaries and everything even have
mysql in the name so everything just works. I'd assume there might be some
divergence in newer features, but I haven't noticed anything in that regard.)

------
SnowingXIV
Running two production applications on 5.1.5. It works swimmingly and I rarely
need to touch it except for some additional feature requests or tweaks.

Is it worth the headache of upgrading to 6.0? I'm looking at the change log
and deprecations and nothing stands out as an issue but I think I still need
to do 5.1.5 to 5.2 then to 6.0. Not to mention I'm not going to utilize any of
the new upgrades.

~~~
ufmace
I'd say it's worth doing, unless you intend to spin down the app entirely in a
couple of years, just for the sake of security updates. You don't want to be
in a situation where there's a vulnerability announced, and you can't pick up
a fix without updating 6 versions, with all of the headaches that brings. It's
worth devoting a few % of time here and there to bumping everything to the
latest version and fixing any issues that come up, and maybe trying to move
things that had been using external gems to any new internal processes that
cover the same tasks.

~~~
SnowingXIV
Good point. It's an app that's got a life left to it. Not much in the way of
changes but it's a pretty critical piece of software. Cloned a copy, moving it
to 5.2 and 6.0. Had to update ruby to 2.5.1. Looks like postgresql (which I
use heavily) is also making comments about migrating data. This is not
seamless. Lots of issues not to mention `rails app:update` basically wipes out
the files, you go back in replace with needed info via diff, more errors. I
thought that was supposed to alleviate that.

If this works I'm hoping at least pushing to Heroku will handle that part.
Heroku notes the gem file and makes the required updates.

------
bigwheeler
A front page Rails-related post that doesn’t have a single comment about rails
scaling issues, 8 entire hours after submission?! It’s a good time to be
alive!!

~~~
wastedhours
Very hard for people to complain about scale when the post's coming direct
from GitHub!

------
dvcrn
This is very interesting. In my bubble I thought the trend was going away from
full fledged batteries included frameworks and more towards “hand pick your
few specific libraries” with Go, Java and what not. Looking into the comments
here, I guess I as wrong.

It’s refreshing to see a big company writing about Rails

~~~
fogetti
It was also just a year ago when Stripe released a static type checker for
Ruby: [https://sorbet.org/](https://sorbet.org/)

Only haters think that Ruby and Ruby on Rails is dead end

------
ezekg
I've actually been having some trouble upgrading from 5.2 to 6.0. I initially
tried upgrading to 6.rc1 but hit a few road blocks, then tried 6.rc2 and just
had too many odd errors and I eventually put that on the back burner. Maybe
I'll go back and revisit, but I had tests failing that I wouldn't initially
expect to fail, such as random unicode errors, broken mailers, and some odd
404s. I may try to upgrade to 6.0, but also kind of feel like waiting until
6.1 is out may be a better option.

(I don't think GitHub talking about their 'smooth update' is fair, given
they've essentially been upgrading to 6.0 since 5.2 released.)

------
_bxg1
Wow, didn't know a company this recognizable was still using (and embracing!)
Rails. Pretty cool. Also helps explain the fact that they've stuck with a
mostly server-side-rendered app, despite it being a fairly complex tool.

~~~
HatchedLake721
Why “still” and “stuck”?

~~~
jaimex2
ignorance

------
xvilka
They should sponsor also the proper JIT in Ruby, will improve the speed
drastically. Not the current generation of C code then compiling it with GCC,
this is a joke.

~~~
save_ferris
How I dream of more serious sponsorship in the ruby community.

I think people underestimate how much python shops are suffering right now
over the V2 to V3 transition. I recently turned down a gig that was basically
just going to be upgrading python services for the next several months.

I've personally preferred much of ruby's tooling and package management to
Python's, and I've always hoped that bigger money would come into the
community. That said, Ruby has done incredible, not knocking the
accomplishments of the community in any way.

~~~
cutler
What happened to IBM? A few years ago they were all in on supporting Ruby.
Next I heard they were betting the company on Swift.

~~~
save_ferris
No idea, but nothing really planned out as far as I’m aware.

It’s great to see companies like Github, Stripe and Shopify make major
contributions to the community, but having a relationship like Google and
Guido have would’ve elevated the community to another level.

------
crispyporkbites
Rails is so productive and powerful these days that if you’re building a web
app you need a really, really good reason not to use it

~~~
StreamBright
I have some: memory usage, CPU usage, raw performance, language safety,
transparency. I think in the era of Elixir/Phoenix, Rust/Actix,
Clojure/Luminus it is really hard to argue for Rails. Don't get me wrong, I
have spent many years on it, but simply there are better alternatives, based
what sort of requirements you got.

~~~
Lordarminius
The main issue I see with these frameworks is that they cannot match Rails'
support ecosystem. The framework has around for a really long while and rails
developers have made - and documented - every error, kink and detour it is
possible to make when writing code. I have often been pleasantly surprised to
google an esoteric problem I imagined could only arise from my own unique
brand of kludginess, and find that the community had encountered and solved
same in the past. This is of massive value especially to new developers.

~~~
StreamBright
I am pretty sure. If you developing the next Basecamp these are essential.
However, I rarely see Rails succeeding in other aspects of web development. I
spent some time on trying to make Rails work for use cases that are not the
perfect match for this ecosystem and failed. Yet, it is quite possible that
there are millions on web applications out there, running on Rails happily. It
is just not a great fit for things I do.

~~~
t0mbstone
And how, exactly, are you differentiating a "Basecamp-like" startup from a
"non-Basecamp" startup?

~~~
hderms
Basecamp's problems seem particularly well suited to a batteries included CRUD
framework. There are plenty of problems out there that aren't CRUD-centric

~~~
StreamBright
Exactly.

------
aledalgrande
If you are struggling to find a way to subscribe to the blog, I found the Atom
feed: [https://github.blog/subscribe/](https://github.blog/subscribe/)

It is not linked anywhere I can see on the main page.

------
phodo
How does one connect a rails 6 app to a python tensor flow (inference) model?

~~~
ssaunier_
As suggested, encapsulate your prediction model in a web service, then calling
it from Rails would be a good way to go.

An other way is to use something like Faktory
([https://contribsys.com/faktory/](https://contribsys.com/faktory/)) on top of
Redis. You push jobs from Rails and then you pull them from Python to execute.
Then Python can enqueue another job with the result which gets consumed by
Rails (async callback).

------
dzonga
unpopular opinion, but the reason people chose node.js is because for some
dense folks like me it's easier to reason about and understand how everything
works. the tooling is abysmal compared to rails, django & laravel. but at
least I know how my app works from top to bottom. you take a productivity hit
in your first node.js project but after that you would've collected / curated
your own personal tools/libraries. and hell yeah spinning an api that does
whatever you want is easy as hell. much respect to dhh though

~~~
moksly
I’m not sure your opinion is unpopular, but I have a hard time following your
logic. Isn’t part of why a solid and curated framework makes perfect sense
(and make you more productive) exactly that you don’t have to understand
everything that’s going on?

I have a decent understanding of what lies beneath linq in C# for instance,
but that’s because I’m curious by nature and not because I had to know it to
utilise it. I mean, I guess you could argue that people should know what’s
going on, but the truth is that 90% of software development doesn’t require
you to, if you pick the right tools.

I think this is a primary reason node.js never really picked up. No one wants
to spend time building and maintain the wheel when you can get a trusted
entity to do it for you. You may find the part about node not picking up odd,
but if I look at job-listings for my entire country there is almost zero
postings for a node backend.

------
jinushaun
Sounds like they upgraded directly from a custom fork of 3.2 to 6.0, but if
you read the article, they upgraded from 5.2 to 6.0. Not as insane as 3->6,
but 3->5 is still pretty insane.

------
aflag
I've never tracking upstream releases of core dependencies so closely. How
does it compare in terms of cost versus doing a big bang upgrade every once in
a while?

~~~
stevenwoo
I have had to take over multiple projects that were years out of date on
multiple platforms/os/languages. It's a nightmare that one does not wish on
anybody, it's possible but as the other poster notes, one has to have
extensive testing suite to verify functionality before and after - or one has
to make one to have any hope of succeeding (making a final product up to date
and functioning correctly unless one just wants to make something just run.)
It's never as easy as just changing the lib/imports since active
languages/libraries are living things, to say nothing of dead libraries that
one has to update or replace.

~~~
tmm84
I agree 100% with this. I once had a project that was versions behind the
current platform. I couldn't upgrade because the tools to upgrade were gone
and I was constantly having to fire off questions to the lead contributor who
was around for that version in order to get stuff done.

Upgrade as soon as a stable build of the major version is released and pay the
engineering costs or be left with something worse than legacy.

------
tomerbd
Long live rails! And this is from a java-spring developer.

------
breatheoften
Why do people like coding in a system where you can cmd-click on almost
nothing to get to any useful information about what the code does ...?

~~~
baroffoos
Some IDEs like rubymine allow this. On vscode if I can't work out what a
function does from the name I just do a full code search for 'def method_name`
and it usually brings up the function I need.

~~~
shantly
> I just do a full code search for 'def method_name` and it usually brings up
> the function I need.

Not in Rails. Too much metaprogramming-generated never-defined stuff going on.
Often makes diving into inherited Rails codebases pretty unpleasant.
Especially if they don't have a solid test suite, which IME most in the wild
do not (not Rails' fault, that's true of most code ecosystems).

~~~
breatheoften
Definitely not sure why this is being downvoted — full text search failing to
find anything about the definition of a symbol in rails codebase is super
super common ... rails obsession with lack of explicit includes is the
stupidest thing I’ve ever encountered in a dynamic programming system ...

Maybe you can get away with a module system that works that way in something
like ocaml where it’s always possible to tell what is being referred to
statically — but in a dynamic language - the level of obfuscation this induces
is absolutely nuts

------
thrownaway954
I have to wait for the MicrosoftSQLServer Adapter to be upgraded before I can
upgrade :(

------
thebiglebrewski
Eileen is a legend! Amazing work over there!

------
EsssM7QVMehFPAs
What about security? Constantly pulling unreviewed code just because it passes
unit or e2e tests does not sound like the ideal choice to me.

~~~
wlll
Code that gets merged into Rails master is reviewed by the Rails core team.

~~~
jrochkind1
And indeed how much of that code gets significantly _more_ review after it's
merged and before release? Some of it.

But yeah, I don't think they were releasing based on unreleased Rails master.
Just running CI, and keeping it passing.

------
developer2
I'm going to stick my neck out as someone who has refused to even _consider_
Rails over a span of many years, for one simple reason: it permits session
fixation. If a client's cookie says "I am session token 'abc123'", it will
create that session id out of thin air. As in, it will create that session id
without it having had to be generated previously. Your memcached/redis does
not have an entry for session 'abc123', but Rails will happily create it.

The developers who allowed this situation to occur should not be permitted to
be employed in our industry. Yes, it's that bad and I am that serious. You
can, not kidding, set your cookie's value to _ANY VALUE YOU WANT_ , and the
codebase is entirely willing to unconditionally create that session with
whatever value the attacker chooses.

Hint: if a client sends session id "abc123", then you should check for the
existence of that session id. If the key is not set, you either a) show an
error page, or b) create a completely new session id, ignoring the client's
requested session id. It is NEVER, EVER, EVER... I am saying ____NEVER__ __,
____EVER__ __acceptable to _create_ a session id based on client-provided
data. And yet, this is what Rails does out of the box.

Edit: Downvote me more, I don't care. The fact is that Rails' developers are
amateurs. Rails is insecure out of the box. That is a fact.

~~~
excid3
The countermeasures to session fixation are covered in the official Rails
guides: [https://guides.rubyonrails.org/security.html#session-
fixatio...](https://guides.rubyonrails.org/security.html#session-fixation-
countermeasures)

~~~
developer2
Why is that an opt-in option? No codebase should _ever_ be willing to create a
session id (any db/cache id/key) based on request details. The fact you have
to _opt in_ to a very basic security measure is, once again, a joke. Let's be
clear: by _default_ , Rails is willing to assign a client any session id based
on its own request?!?!

Based on the other reply to my comment... no I'm not OK. I am _not_ OK with
Rails' pathetic attempts at the most basic level of security. Rails'
developers are fucking amateurs. I'm sorry, but that's pure fact. Rails'
developers don't know the first thing about the HTTP protocol.

NOBODY EVER CREATES A DB/CACHE KEY BASED ON THE VALUE OF A CLIENT-PROVIDED
COOKIE (or unvalidated GET/POST). Anyone who argues against this should be
permanently banned from IT/Technology. Just... fuck off... you have no clue.

~~~
codeisawesome
You may have a valid point but your rant-y syntax is what’s earning you the
downvotes :/

