Deploying modern web apps – with all the provisions needed to be fast and secure while easily updateable – has become so hard that many developers don’t dare do it without a PaaS (platform-as-a-service). But that’s ridiculous. Nobody should have to pay orders of magnitude more for basic computing just to make deployment friendly and usable. That’s a job for open source, and Rails 8 is ready to solve it.

t.column :created_at, :timestamptz, null: false

Enhances ActionMailer to support the :cache delivery method, which behaves like :test, except that the deliveries are marshalled to a temporary cache file, thus making them available to other processes.

This is classic Rails Magic - a clever side effect that guarantees the token in the session cookie will always match the token on the page, because rendering the token to the page can't happen without inserting that same token into the cookie.

You'll need to either stop transpiling or use a Node-based transpiler, like those in jsbundling-rails and cssbundling-rails.

The asset pipeline is a collection of components that work together. Here's a list of what they might be.Concatenation for merging together many files into one big file.Minification for compressing the contents of a file to make it smaller in size.Pre-compilation for using your language of choice to write CSS or Javascript.Fingerprinting to force reloading of asset changes (i.e., cache busing).

I can confirm that this is still actual for Rails 7 - jpEg converts to jpg and your production fails.

Personally I’m not a fan of running migrations in an ENTRYPOINT script.I think it’s best suited to run this separately as part of your deploy process

Performing a redirect by constructing a URL based on user input is inherently risky, and is a well-documented security vulnerability. This is essentially what you are doing when you call redirect_to params.merge(...), because params can contain arbitrary data the user has appended to the URL.

Some frameworks call this “template inheritance”. In this example, we might say that the application layout “inherits from” or “extends” the base layout. In Rails, this is known as nested layouts, and it is a bit awkward to use. The standard Rails practice for nested layouts is complicated and involves these considerations

But what if you want to reuse one layout within another?

On reload, the namespaces are safe, won't be reloaded. The loader only reloads what it manages, which in this case is the adapter itself.

In this example, we still want app/models/shapes/circle.rb to define Circle, not Shapes::Circle. This may be your personal preference to keep things simple, and also avoids refactors in existing code bases. The collapsing feature of Zeitwerk allows us to do that:

pp Rails.autoloaders.main.dirs

People want to autoload from lib, which is understandable. If we can, this use case should have first-class support from the framework.

authenticate_by addresses the vulnerability by taking the same amount of time regardless of whether a user with a matching email is found: User.authenticate_by(email: "...", password: "...")

helper.singleton_class.include Rails.application.routes.url_helpers

ArgumentError: arguments passed to url_for can't be handled. Please require routes or provide your own implementation

t.daterange :period

What can we do to undo this commit?

I assume that the ActiveStorage::Attachment class gets reloaded dynamically and that the extensions are lost as they are only added during initialization. You’re correct. Use Rails.configuration.to_prepare to mix your module in after application boot and every time code is reloaded: Rails.configuration.to_prepare do ActiveStorage::Attachment.send :include, ::ActiveStorageAttachmentExtension end

before_action -> { doorkeeper_authorize! :public }, only: :index

What you're actually trying to do is to have the exact same behaviour that native Devise implementation but on an Engine via API

Our test raises an ActiveRecord::RecordNotFound exception. We know that Rails has special handling to return a 404 status code in this case. However, the request spec still raises the exception.

The reason is Rails only reads and creates the session object when it receives the request and writes it back to session store when request is complete and is about to be returned to user.

Session race conditions are very common in Rails. Redis session store doesn't help either! The reason is Rails only reads and creates the session object when it receives the request and writes it back to session store when request is complete and is about to be returned to user.

As you can see from the example, the session cookie is updated on every request, regardless of if the session was modified or not. Depending on when the response gets back to the client last, thats the cookie that will be used in the next call. For example, if in our previous example, if get_current_result’s response was slower than get_quiz, then our cookie would have the correct data and the next call to update_response would of work fine! So sometimes it will work and sometimes not all depending on the internet gods. This type of race condition is no fun to deal with. The implications of this is that using cookie storage for sessions when you are doing multiple ajax call is just not safe.

A better solution would be to use a server side session store like active record or memcache. Doing so prevents the session data from being reliant on client side cookies. Session data no longer has to be passed between the client and the server which means no more potential race conditions when two ajax are simultaneously made!

When configuring SMTP settings in an after_initialize block, the settings aren't picked up by ActionMailer. This leads to runtime errors, since ActionMailer tries the default settings.

It really only takes one head scratching issue to suck up all the time it saves you over a year, and in my experience these head scratchers happen much more often than once a year. So in that sense it's not worth it, and the first time I run into an issue with it, I disable it completely.

Overriding the ActiveStorage controllers to add authentication or customize behavior is a bit tedious because it requires either: using custom routes, which means losing the nice url helpers provided by active storage copy pasting the routes in the application routes.rb, which is not very DRY.

it should be normal for production apps to add authentication and authorization to their ActiveStorage controllers. Unfortunately, there are 2 possible ways to achieve it currently: Not drawing ActiveStorage routes and do everything by yourself Override/monkey patch ActiveStorage controllers None of them is ideal because in the end you can't benefit from Rails upgrades (bug fixes, etc) so the intention of this PR is to let people define a parent controller (inspired by Devise, maybe @carlosantoniodasilva can tell us his experience on this feature) so that people can add authentication and authorization in a single place and still benefit from the default controllers.

The combined stuff is available to components using the page store as $page.stuff, providing a mechanism for pages to pass data 'upward' to layouts.

after_commit { puts "We're all done!" }

In Rails, this is known as nested layouts, and it is a bit awkward to use. The standard Rails practice for nested layouts is complicated and involves these considerations:

As of Rails 7.0+, Active Record has an option for handling associations that would perform a join across multiple databases.

You can also use silence_redefinition_of_method if you need to define the replacement method yourself (because you're using delegate, for example).

composed_of attr, :class_name => 'AddressableRecord::Address', :converter => :convert, :allow_nil => true,

belongs_to :city

belongs_to :zipcode

acts_as_tokened Quickly adds rails 5 has_secure_token to your model, along with some Post.find() enhancements to work with tokens instead of IDs.

include Effective::CrudController

# All queries and objects will be built with this scope resource_scope -> { current_user.posts } # Similar to above, with block syntax resource_scope do Post.active.where(user: current_user) end

enumerate_by :alpha_2_code

403 :forbidden

401 :unauthorized

Rails 5 recently shipped, and among many other new features is a new renderer that makes it easy to render fully composed views outside of your controllers.

1) Order the one for your particular vehicle if you can otherwise the curvature of the side rails may not be correct which will dent the metal once secured.2) Look/feel under the headliner if you can prior to drilling into the roof, you may hit a beam which will be troublesome running a screw through multiple pieces of metal. You can also cut the side rails if necessary.3) Use non-corrosive silicone (does not smell like vinegar which will eventually eat away at the paint and rust) to seal up the holes that you drill into the roof. End caps doesn't appear to make a tight seal.4) Screws are stainless which are typically soft. Be careful not to overnighten! I actually used a rivnut/blind nut tool instead of just screws (About 25 bucks here on Amazon).

Rails' inability to automatically route my link_to and form_for in STI subclasses to the superclass is a constant source of frustration to me. +1 for fixing this bug.

I don't like that I can't really use head? to know it's a HEAD request, but I (think I) understand the reasoning

As you can see Rails already adds error messages from associated models and doing it wrongly: Merging together errors from different models under same has_many association. :"employments.company"=>["can't be blank"] And this is wrong.

So ActionCable needs Redis! Is this the first time Rails is aligning with a vendor product? Why not abstract it like AR/AJ?

While rails does have nice CSRF protection, in my instance it limited me.

GitLab is transitioning from controller specs to request specs.

# unauthenticated do # as :user do # root to: 'devise/registrations#new' # end # end

# authenticated :user, lambda {|u| u.role == "admin"} do # root to: "admin/dashboard#show", as: :user_root # end

There is no request.env in functional tests because the functional tests are supposed to remain at the controller level.

This is a Rails change of behaviour and Rails is not going back.

class LoggedInConstraint def self.matches?(request) request.env['warden'].authenticate? end end

class AuthConstraint def initialize(&block) @block = block || ->(_) { true } end def matches?(req) user = current_user(req) user.present? && @block.call(user) end def current_user(req) User.find_by_id(session[:user_id]) end end This is a flexible approach to defining route access based on any desired variable (roles, auth, etc...)

scope module: 'authenticated', constraints: AuthConstraint.new { |user| user.present? } do # Management dashboard root 'dashboards#index' end root 'home#index'

authenticated :user do root 'calendars#index', as: :authenticated_root end unauthenticated :user do root 'pages#home', as: :unauthenticated_root end

You can also specify constraints as a lambda:

Meh... as I said earlier, I think using Webpack is the recommended way now. Another issue is there is no way to generate source maps in production.

But last I have seen comments from DHH, he considered webpack(er) recommended for JS, but Sprockets still the preferred solution for (S)CSS.

I agree about lack of maintenance. It's probably because people use more and more Webpack.

we want source maps in production (like DHH)

After waiting years for sprockets to support this we were very happy to see that sprockets 4 officially added support (thanks ), but then when trying to upgrade we noticed there's actually no way to use it in production... (without brittle hacks mentioned above).

Rails still encourages you to dump all validation errors at the top of a form, which is lulzy in this age of touchy UX

Run the complete unit with a certain input set, and test the side-effects. This differs to the Rails Way™ testing style, where smaller units of code, such as a specific validation or a callback, are tested in complete isolation. While that might look tempting and clean, it will create a test environment that is not identical to what happens in production.

Responders don't use valid? to check for errors in models to figure out if the request was successful or not, and relies on your controllers to call save or create to trigger the validations.

Instead of dealing with a mix of before_filters, Rack-middlewares, controller code and callbacks, an endpoint is just another activity and allows to be customized with the well-established Trailblazer mechanics.

The legendary cfp-app will become a Rails-to-TRB refactoring tutorial.

To make it short: we returned to the Rails Way™, lowering our heads in shame, and adhere to the Rails file and class naming structure for operations.