Adding `clearance/rspec` to `spec/spec_helper.rb` in RSpec versions greater or equal to 3 will throw an `uninitialized constant Module::ActiveSupport` error, since the Rails env is not available. This updates the README in order to indicate the require statement should be placed in `spec/rails_helper.rb`.
As a result: * In the ActionMailer initializer for the test app, we have to refer to the ActionMailer object itself to configure it instead of the app config. This was recommended in rspec/rspec-rails#1313. * We had to change the setup for rack_session_spec because RSpec now checks for mutation of arguments passed into spies.
This line has existed since 2008, and yet I can determine no justification for it. It seems to me that we *would* want CSRF protection on `session#create`. On its own, skipping CSRF protection in just this single action doesn't seem particularly useful to an attacker. Additional vectors (such as an overly-permissive CORS header) would have to be present to make use of this, but at that point far more interesting attacks would be possible on any cookie-based auth system.
I took a pass through the README file and edited for brevity, organization, and correctness. I eliminated the various lists of overrideable methods as these were out of date and not particularly helpful in themselves. We already point the users to the overridable classes. Over time I'd like to move the overriding and extending documentation into the yarddoc itself or into a website that has recipes for various behaviors people often request. For now, I've slimmed some of it down but left most of it. I also removed reference to the `deny_access` matcher as it will soon be removed (to another gem) and I don't suggest its use.
The nested `before` blocks caused a great deal of frustration when adding additional tests to password reset functionality. The specs were re-written in a style consistent with how we write specs today, taking care to ensure tests still fail appropriately.
These methods should be tested separately instead of nested within each other.
The `authorize` before filter is deprecated in favor of `require_login`. However, just switching Clearance's internal filters is not sufficient. We're dependent on users updating any `before_filter :authorize` calls. If they still have `before_filter :authorize` in their application controller, then they will see a deprecation on calls to authorize but the method will still run (it's aliased to `require_login`). This may cause them to be redirected to sign in. Sign in is set to `skip_before_filter :require_login`, but will happily still run authorize if instructed to by the application controller. Then you're stuck in a redirect loop. By duplicating the `skip_before_filter` calls to also skip `authorize` we can be sure this doesn't happen.
This adds a `before_filter` for `sessions#new` that will redirect signed in users to the same url that is configured for `url_after_create`, which, by default, points to `Clearance.configuration.redirect_url`.
The replacement spec does much the same as the features were doing before, but in a (hopefully) more maintainable manner. We generate a fresh rails app, install clearance, and run clearance's generated specs. I kept the acceptance spec in its own suite because the output of it is a bit odd and I wanted it separate from our usual tests. It will output the results of the generated specs followed by the result of the single acceptance spec.
To get the test suite to run in under 2.2, I: * Upgraded Cucumber to a version that supports Ruby 2.2 * Added 2.2.0 to our Travis Matrix (Sorry, Travis) * Excluded Rails 3.2 under Ruby 2.2 from appraisals as it is not supported by rails (yet). See: rails/rails#18306 Once that was done, it was discovered that Rails 4.0.x requires the `test-unit` gem under Ruby 2.2. Adding that gem allows the test suite to run there. With that in place, I found that the `deny_access` matcher was not negating as expected. This is because the test-unit gem raises a different error when an assertion failed. I have to catch this error in addition to the Minitest::Assertion error we were already catching.
This appears to have been a convenience method used only in a single generator. While the replacement is uglier it has the distinct advantage of not leaking into the public API of the gem. It's unlikely anyone is using this method externally, but I added a deprecation just in case. The method will be removed in 2.0.
This name better expresses the intent of the filter and has the advantage of not conflicting with the `authorize` method provided by pundit or wading into the sometimes hairy line demarcating authorization from authentication. Clearance users should migrate from `:authorize` to `require_login` as the former will be removed in 2.0. Be sure to catch reference to `skip_before_filter :authorize` or `skip_before_action :authorize`, which the deprecation cannot catch. addresses #503, #436, and #239
There's no sense in setting a remember token cookie if the value of that cookie is nil. In fact, this causes a problem for sites that bounce users between HTTP and HTTPS connections for when the user is signed in versus signed out. Prior to this change, if Clearance's `secure_cookie` option was on the users remember token would be completely wiped out when they hit an HTTP page. Even returning to HTTPS would not restore the user's token. With this change in place, the HTTP response would simply not set a remember token cookie, but switching back to HTTPS would allow the client to send its previously existing cookie. There was an existing test for this, but it was passing incorrectly. The `set_cookie` matcher was not negating the way we wanted it to. On the test, the header values were: Fixes #338.
* Instance variables should be defined in initializers before used * `File.exists?` is deprecated This does not address the "possible reference to past scope" warnings introduced with Ruby 2.2.0 as it appears this warning will be removed in 2.2.1. See https://bugs.ruby-lang.org/issues/10661