| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
activesupport/lib/active_support/core_ext/hash/slice.rb
guides/source/active_support_core_extensions.md
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
bdd105d changes the behaviour of AC::Parameters#permit.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
all the hash
params.require(:person).permit(:projects_attributes) was returning
=> {"projects_attributes"=>{"0"=>{"name"=>"Project 1"}}}
When should return
=> {}
You should be doing ...
params.require(:person).permit(projects_attributes: :name)
to get just the projects attributes you want to allow
|
|
|
|
|
|
| |
to the block.
Thanks @tenderlove
|
|
|
|
|
|
|
| |
This will make easier to permit date/time attributes generated by
helpers like date_select.
[Sven Schwyn + Rafael Mendonça França]
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
actionpack/lib/action_view/helpers/asset_tag_helper.rb
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
IndexError
|
| |
|
|
|
|
| |
StrongParameters protection
|
|
|
|
| |
AC::Metal::ParamsWrapper
|
| |
|
|
|
|
|
|
| |
See
http://travis-ci.org/#!/rails/rails/jobs/2444632
|
|
|
|
|
|
|
|
| |
It's further work on CSRF after 245941101b1ea00a9b1af613c20b0ee994a43946.
The :null_session CSRF protection method provide an empty session during
request processing but doesn't reset it completely (as :reset_session
does).
|
| |
|
| |
|
|
|
|
|
|
|
| |
Method invalid_asset_host! was delegated to controller but sprockets
compile assets in their own scope without controller. And if we set asset_host
with second parameter it should raise error through invalid_asset_host!.
But since controller is nil it cannot be reached.
|
|
|
| |
Since it uses request and response methods
|
| |
|
| |
|
|
|
|
| |
computation *Jeremy Kemper/DHH*
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many named routes have keys that are required to successfully resolve. If a key is left off like this:
<%= link_to 'user', user_path %>
This will produce an error like this:
No route matches {:action=>"show", :controller=>"users"}
Since we know that the :id is missing, we can add extra debugging information to the error message.
No route matches {:action=>"show", :controller=>"users"} missing required keys: [:id]
This will help new and seasoned developers look closer at their parameters. I've also subclassed the routing error to be clear that this error is a result of attempting to generate a url and not because the user is trying to visit a bad url.
While this may sound trivial this error message is misleading and confuses most developers. The important part isn't what's in the options its's what's missing. Adding this information to the error message will make debugging much more obvious.
This is the sister pull request of https://github.com/rails/journey/pull/44 which will be required to get they missing keys into the correct error message.
Example Development Error in Rails: http://cl.ly/image/3S0T0n1T3421
|
|
|
|
|
| |
When module is extended ActiveSupport::Concern, include calls are lazily
loaded, so there is no need to wrap it with included hook.
|
|
|
|
|
|
| |
Since Action View should not depend on actionpack, it's best to delegate
invalid_asset_host! to controller and just rely on such simple contract
instead of raising ActionController::RoutingError directly.
|
|\ |
|
| | |
|
| |
| |
| |
| | |
their own header object
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When you mount your application at a path, for example /myapp, server
should set SCRIPT_NAME to /myapp. With such information, rails
application knows that it's mounted at /myapp path and it should generate
routes relative to that path.
Before this patch, rails handled SCRIPT_NAME correctly only for regular
apps, but it failed to do it for mounted engines. The solution was to
hardcode default_url_options[:script_name], which is not the best answer
- it will work only when application is mounted at a fixed path.
This patch fixes the situation by respecting original value of
SCRIPT_NAME when generating application's routes from engine and the
other way round - when you generate engine's routes from application.
This is done by using one of 2 pieces of information in env - current
SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because
we have 2 cases to handle:
- generating engine's route from application: in this situation
SCRIPT_NAME is basically SCRIPT_NAME set by the server and it
indicates the place where application is mounted, so we can just pass
it as :original_script_name in url_options. :original_script_name is
used because if we use :script_name, router will ignore generating
prefix for engine
- generating application's route from engine: in this situation we
already lost information about the SCRIPT_NAME that server used. For
example if application is mounted at /myapp and engine is mounted at
/blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that
we need to keep reference to /myapp SCRIPT_NAME by binding it to the
current router. Later on we can extract it and use when generating url
Please note that starting from now you *should not* use
default_url_options[:script_name] explicitly if your server already
passes correct SCRIPT_NAME to rack env.
(closes #6933)
|