Consider Removing `use_inertia_instance_props`

[BrandonShar]

I am currently not convinced we should remove this functionality. As I said in #239, I view this feature as a sharp knife and believe it's a nice opt-in for folks who understand what they're getting into. BUT, I do understand the objection and want to make sure I'm not dismissing it too quickly. So this issue is to understand community sentiment on this feature. If you have an opinion, please add it below!

As @skryukov said in the original PR #239 :

While use_inertia_instance_props is a clever way to mimic Rails behavior, it also exposes too much data on the frontend side, which is very dangerous. Therefore, I propose deprecating it.

And @bknoles replied:

Ok, I'm following now. So, I'd say something like this isn't super risky and is a sharp knives situation:

class MyController
  before_action :check_something_expensive
  use_inertia_instance_props
  
  def index
    @other_thing = OtherThing.find(params[:id])

    render inertia: 'OtherThing/Show'
  end
  
  # non-Inertia action
  def other_action
    # Reason for memoizing
    render json: my_expensive_thing
  end

  protected

  def check_something_expensive
    raise 'Uh oh' if my_expensive_thing.broken?
  end

  def my_expensive_thing
    @_my_expensive_thing ||= ExpensiveCalc.new.calculate
  end
end

However this one would worry me:

class MyController < ApplicationController
  include AwesomeLLMHelperFromGem
  use_inertia_instance_props

  def index
    @thing = Thing.find(params[:id])

    render inertia: 'Things/Show'
  end
end

# Inside gem
module AwesomeLLMHelperFromGem
  included do
    before_action do
      @_openai_token = OpenAI.authenticate(some_stuff)
    end
  end

  ...
end 

That one would (probably suprisingly) ship credentials right into the Inertia response. As I look through the code, @_inertia_skip_props seems intended to mitigate the risk, but it's going to depend on the order that the before_actions are registered / order of operations, etc.

[bknoles]

What about changing the API to be an allow list?

class MyController < ApplicationController
  use_inertia_instance_props :thing, :other_thing

  def first_action
    @thing = Thing.find(params[:thing_id])

    render inertia: 'Things/FirstAction'
  end

  def second_action
    @other_thing = OtherThing.find(params[:other_thing_id])

    render inertia: 'OtherThings/SecondAction'
  end

  def third_action
    # This would NOT be passed to the client as a prop
    thing = Thing.find(params[:thing_id])
    thing.do_something

    render inertia: 'SomeOtherPage'
  end
end

It's less elegant, but still a bit cleaner than the default prop passing for those who love to squeeze code out of their controllers. And it removes the risk of accidentally exposing something to the client.

(This thought inspired by the decent_exposure library that a teammate sent my way)

[skryukov]

I don't see the point in this vs explicit 'render inertia: foo:, bar:'

[bknoles]

I think it's just a stylistic preference. The hypothetical user of use_inertia_instance_props (which I am not) doesn't mind explicitly passing a page path but prefers not to have to manually craft a props object. Or maybe they also use default_render so that their controller actions look even leaner?

class MyController < ApplicationController
  # probably in a base controller or initializer
  inertia_config(default_render: true)

  use_inertia_instance_props :thing

  def show
    @thing = Thing.find(params[:id])
  end
end

(That would theoretically work, right?)

Personally, I prefer to explicitly render both the page path and the props object. All these renderer tricks are too much magic for my taste but I don't mind accommodating the crazy people reasonable-people-who-disagree-with-me that like them 😁.

[darkamenosa]

I used this, I like this. But I faced a few situations:

• Use instance variable to cache something -> it also serialize
• Sometimes, my variable has some kind of secret, but I forgot -> it's also serialized to frontend.

[theconektd]

TL;DR Make it configurable. Disable by default. Prompt in the generator.

I'm new this project, but upon reading the docs I had a very similar feeling reading about responses.

In addition to use_inertia_instance_props the other big one being that the renderer serializes everything by default.

For my projects, I would prefer that 1) use_inertia_instance_props wasn't even an option and that 2) the renderer serialized nothing by default and required me to list the props I want send to the browser.

I also realize that use_inertia_instance_props is probably quite expedient in a high-trust environment; as is the default performance of the renderer. I don't want to take that away from people who understand the risks and want to leverage it.

However, I would say that for any kind of public-facing application these things being the default constitutes a significant foot-gun and banning use_inertia_instance_props and requiring all controllers to explicitly list the props being sent would be a matter of rigor for any project. People make mistakes and in a team setting it's way too easy for me to send an entire object to the browser when I know it has nothing spicy, time passes and then a teammate adds something spicy to the model which is now there for all to see.

The docs are very clear about the the security and performance risks inherent in using the former and explain how to mitigate the risks in the latter by explicitly listing the props you want to serialize. I respect this, however it presumes that the user will actually read the docs and if they don't they are almost guaranteed to unknowing leak data to users at some point.

Given this I suggest the following:

• Add a configuration option akin to allow_use_inertia_instance_props which defaults to false. The method could just raise an error when false to prevent its use.
• Add a configuration option akin to implicitly_serialize_models which default to false. When false you have to explicitly list the props you want to send. And alternative would be to just raise an error unless the props argument is provided.
• Have the generator prompt you about the setting in which your app is intended and choose sensible defaults based on the deployment.

What do y'all think?

[darkamenosa]

Maybe just keep it, then add something like filter_parameters of rails.

Rails.application.config.filter_parameters += [
  :passw, :email, :secret, :token, :_key, :crypt, :salt, :certificate, :otp, :ssn, :cvv, :cvc
]

Just to not accident sezialize token, etc ...

For example:

InertiaRails.configure do |config|

  # Transform snake_case props to camelCase for JavaScript frontend
  config.prop_transformer = lambda do |props:|
    props.deep_transform_keys { |key| key.to_s.camelize(:lower) }
  end
   
   config.filter_prop = [:token, :password]
end

[osbre]

I wanted to have Laravel-like unintrusive serialization on models, so made this:

class OauthAccount < ApplicationRecord
  # ...

  hide :refresh_token
end

model_serialization.rb

class ApplicationRecord < ActiveRecord::Base
  primary_abstract_class

  include ModelSerialization
end

Be warned: this was made from AI assistance. A hand-crafted version by experienced hand is going to be better.

# frozen_string_literal: true

module ModelSerialization
  extend ActiveSupport::Concern

  included do
    # Laravel-ish:
    #   self.hidden  += %i[password_digest]
    #   self.visible += %i[id email]
    class_attribute :hidden, instance_writer: false, default: []
    class_attribute :visible, instance_writer: false, default: nil
  end

  class_methods do
    # Nice DSL:
    #   hide :password_digest, :api_token
    #   show :id, :email, :name
    def hide(*attrs)
      self.hidden |= attrs.flatten.map!(&:to_sym)
    end

    def show(*attrs)
      self.visible = attrs.flatten.map!(&:to_sym)
    end
  end

  # Rails calls this for render json:, as_json, to_json, etc.
  def serializable_hash(options = nil)
    options = (options || {}).dup

    # Respect caller intent, but apply model defaults.
    only   = Array(options[:only]).map!(&:to_sym) if options.key?(:only)
    except = Array(options[:except]).map!(&:to_sym)

    if only
      # If caller provided :only, we don't fight it—just pass through,
      # but still allow them to "subtract" via :except.
      options[:only] = only
    elsif self.class.visible
      # If model has visible, it’s the default whitelist.
      options[:only] = self.class.visible
    end

    # Always apply hidden unless caller explicitly chose :only that excludes them anyway.
    options[:except] = except | self.class.hidden

    super(options)
  end
end

Coming from Laravel, this feels like it needs to be in Rails core :P

[buhrmi]

As an avid user of this function, I just wanted to note that the above example code does NOT leak credentials:

class MyController < ApplicationController
  include AwesomeLLMHelperFromGem
  use_inertia_instance_props

  def index
    @thing = Thing.find(params[:id])

    render inertia: 'Things/Show'
  end
end

# Inside gem
module AwesomeLLMHelperFromGem
  included do
    before_action do
      @_openai_token = OpenAI.authenticate(some_stuff)
    end
  end

  ...
end 

This code is safe because the include AwesomeLLMHelperFromGem appears BEFORE the use_inertia_instance_props call. If include AwesomeLLMHelperFromGem were to appear AFTER the user_inertia_instance_props call, it would indeed leak the credentials.