- 31 12月, 2019 1 次提交
-
-
由 Carlos Antonio da Silva 提交于
-
- 28 12月, 2019 1 次提交
-
-
由 Haroon Ahmed 提交于
-
- 26 12月, 2019 1 次提交
-
-
由 Joe Marty 提交于
Addresses some comments in original PR for docs on using session management middleware in API apps
-
- 07 8月, 2019 1 次提交
-
-
由 Akshay Mohite 提交于
- Using `mem_cached_store` results in an exception as lib/active_support/cache.rb:106:in `rescue in retrieve_store_class': Could not find cache store adapter for mem_cached_store (cannot load such file -- active_support/cache/mem_cached_store) (RuntimeError) - Changed the name of cache_store as `mem_cache_store` instead of `mem_cached_store`
-
- 23 4月, 2019 1 次提交
-
-
由 st0012 提交于
Rails doesn't support view caching in api controllers by default but the document didn't clearerly declare this nor the manual config needed after including the module manually. So we'll see people get confused like #35602.
-
- 07 3月, 2019 1 次提交
-
-
由 Nathaniel Suchy 提交于
-
- 03 2月, 2019 1 次提交
-
-
由 Genadi Samokovarov 提交于
During the development of #33145, I have named a few concepts in the code as `whitelisted`. We decided to stay away from the term and I adjusted most of the code afterwards, but here are the cases I forgot to change. I also found a case in the API guide that we could have cleaned up as well. [ci skip]
-
- 24 7月, 2018 1 次提交
-
-
由 Paul McMahon 提交于
http links will be redirected to the https version, but still better to just directly link to the https version.
-
- 07 7月, 2018 1 次提交
-
-
由 Alberto Almagro 提交于
As discussed in #33203 rails command already looks for, and runs, bin/rails if it is present. We were mixing recommendations within guides and USAGE guidelines, in some files we recommended using rails, in others bin/rails and in some cases we even had both options mixed together.
-
- 11 5月, 2018 1 次提交
-
-
由 Anthony Crumley 提交于
[ci skip] A regular expression was used to find a lot of missing Oxford commas and add them. The regular expression was as follows. ", ([a-zA-Z0-9.\`:'\"]+ ){1,6}(or|and) "
-
- 31 3月, 2018 1 次提交
-
-
由 Yoshiyuki Hirano 提交于
* The twitter developer site's url was changed.
-
- 30 3月, 2018 1 次提交
-
-
由 Derek Prior 提交于
Today there are two common ways for Rails developers to force their applications to communicate over HTTPS: * `config.force_ssl` is a setting in environment configurations that enables the `ActionDispatch::SSL` middleware. With this middleware enabled, all HTTP communication to your application will be redirected to HTTPS. The middleware also takes care of other best practices by setting HSTS headers, upgrading all cookies to secure only, etc. * The `force_ssl` controller method redirects HTTP requests to certain controllers to HTTPS. As a consultant, I've seen many applications with misconfigured HTTPS setups due to developers adding `force_ssl` to `ApplicationController` and not enabling `config.force_ssl`. With this configuration, many application requests can be served over HTTP such as assets, requests that hit mounted engines, etc. In addition, because cookies are not upgraded to secure only in this configuration and HSTS headers are not set, it's possible for cookies that are meant to be secure to be sent over HTTP. The confusion between these two methods of forcing HTTPS is compounded by the fact that they share an identical name. This makes finding documentation on the "right" method confusing. HTTPS throughout is quickly becomming table stakes for all web sites. Sites are expected to operate over HTTPS for all communication, sensitive or otherwise. Let's encourage use of the broader-reaching `ActionDispatch::SSL` middleware and elminate this source of user confusion. If, for some reason, applications need to expose certain endpoints over HTTP they can do so by properly configuring `config.ssl_options`.
-
- 15 12月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
[ci skip] Add missing **DO NOT READ THIS FILE ON GITHUB, GUIDES ARE PUBLISHED ON http://guides.rubyonrails.org.**
-
- 20 11月, 2017 1 次提交
-
-
由 Roman Kovtunenko 提交于
-
- 24 9月, 2017 1 次提交
-
-
由 Yoshiyuki Hirano 提交于
* `MyApi::Application::Routes` is not middleware.
-
- 23 8月, 2017 1 次提交
-
-
由 Yoshiyuki Hirano 提交于
-
- 19 8月, 2017 1 次提交
-
-
由 Yoshiyuki Hirano 提交于
-
- 21 5月, 2017 1 次提交
-
-
由 Mike Gunderloy 提交于
* Adjust list of middlewares loaded by default * Add routing middleware to list to match the list in the Rack guide * Adjust list of Controller modules loaded by default Plus fix one singular/plural mistake
-
- 15 2月, 2017 1 次提交
-
-
由 Joe Marty 提交于
Without this, it's not clear that session middleware has special cases to handle with the `api_only` flag
-
- 16 5月, 2016 2 次提交
- 14 5月, 2016 1 次提交
-
-
由 Vipul A M 提交于
Add output snippet from `ActionController::API.ancestors - ActionController::Metal.ancestors` command for api apps. [ci skip]
-
- 11 5月, 2016 1 次提交
-
-
由 Vipul A M 提交于
Remove ambiquity in what we are referring to in the documentation of config vs configuring the server itself
-
- 01 5月, 2016 2 次提交
-
-
由 willnet 提交于
Guides should be updated because ActionDispatch::LoadInterlock was replaced with ActionDispatch::Executor at #23807.
-
由 yuuji.yaginuma 提交于
-
- 23 4月, 2016 1 次提交
-
-
由 Vipul A M 提交于
[ci skip]
-
- 22 4月, 2016 1 次提交
-
-
由 Prathamesh Sonpatki 提交于
[ci skip]
-
- 20 4月, 2016 1 次提交
-
-
由 Vipul A M 提交于
[ci skip]
-
- 25 2月, 2016 1 次提交
-
-
由 Akshay 提交于
- #23771 removed the reference to debug_exception_response_format from the api_app documentation. - We need to let users know, they have ability to configure debug_exception_response_format in their development environment. - Added documentation for the same in api_app.md file - Grammar corrections
-
- 19 2月, 2016 2 次提交
-
-
由 yuuji.yaginuma 提交于
Since a0343d11, `debug_exception_response_format` config depends on `api_only`. Therefore, if set the `api_only`, need to specify `debug_exception_response_format` is not.
-
由 Xavier Noria 提交于
-
- 07 2月, 2016 1 次提交
-
-
由 Vijay Dev 提交于
[ci skip]
-
- 01 2月, 2016 1 次提交
-
-
由 Bart de Water 提交于
-
- 29 1月, 2016 3 次提交
-
-
由 Jon Moss 提交于
Pass through correcting api_app.md. The list of included modules and middleware was tested through a sample API app, and was listed in the same order an end user would see in their terminal. [ci skip]
-
由 Rafael Mendonça França 提交于
It is not always there anymore [ci skip]
-
由 Rafael Mendonça França 提交于
[ci skip]
-
- 18 12月, 2015 1 次提交
-
-
由 David Heinemeier Hansson 提交于
Still more to do. Please assist!
-
- 09 12月, 2015 1 次提交
-
-
由 Jorge Bejar 提交于
-
- 19 11月, 2015 1 次提交
-
-
由 zacharywelch 提交于
-
- 04 10月, 2015 1 次提交
-
-
由 Aaron Patterson 提交于
This reverts commit 37423e4f. Jeremy is right that we shouldn't remove this. The fact is that many engines are depending on this middleware to be in the default stack. This ties our hands and forces us to keep the middleware in the stack so that engines will work. To be extremely clear, I think this is another smell of "the rack stack" that we have in place. When manipulating middleware, we should have meaningful names for places in the req / res lifecycle **not** have engines depend on a particular constant be in a particular place in the stack. This is a weakness of the API that we have to figure out a way to address before removing the constant. As far as timing attacks are concerned, we can reduce the granularity such that it isn't useful information for hackers, but is still useful for developers.
-