If the return_to url has a query string attached to it, we want to be sure we are including it when clearance redirects. URI::HTTP has the wonderful `request_uri` method that returns us the path and query string together, but our session variable stores only `fullpath` which URI parses as URI::Generic. That means we have to assemble the path and query string ourselves.
* remove unnecessary quoting * apply consistent sorting of keys
There is a configuration option that allows for sign up to easily be disabled. With this enabled, the `sign_up_path` route helper is not defined. This causes a 500 when a user login fails because the default I18n message uses `sign_up_path` for interpolation. I opted to remove the interpolation, and thus the sign up link, from the default sign in failure message. This is perhaps somewhat less helpful, but it makes for a working out of the box experience for people who disable sign up. An alternative would be to add another flash message specifically for this case and add conditionals to `DefaultSignInGuard` (or a helper object) to handle it. I felt that the increased complexity of that solution wasn't worth it.
Travis frequently has timeout problems when contacting rubygems. Travis supplies the `travis_retry` command to help combat this. This will retry the install up to 3 times. This will not help when appraisal tries to install its missing dependencies. Changes for that are probably best left to appraisal.
Rails 4.1 now includes jbuilder 2.0+ in its default gemfile. Move the jbuilder 1.2 dependency from the clearance `gemfile` into the appraisals for Rails < 4.1 and add jbuilder 2.0 to the Rails 4.1 appraisal. The sdoc dependency was also moved into the appraisal definitions because it is a dependency only because it is included in the rails default gemfile. This leaves the gemfile for development dependencies only. Renamed the `create_migration` method in the Clearance install generator because it was [conflicting with a method] that was added into the class hierarchy in Rails 4.1. : https://github.com/rails/rails/blob/master/railties/lib/rails/generators/migration.rb#L63
* rspec helper `lib/clearance/rspec.rb` * test-unit helper `lib/clearance/test_unit.rb` * print out a deprecation warning when `clearance/testing` is required Use Kernel.warn for deprecation message
The sign_in helper requires FactoryGirl to create a user. FactoryGirl isn't a dependency of the Gem and we wouldn't want it to be because we don't want it loaded in production. Raise a more helpful error if someone tries to use the `sign_in` test helper without having FactoryGirl. Additionally remove the hard-coded `:user` factory in favor of a factory named for whatever the configred user model is.
The password reset controller was previously assuming that the id parameter would be available as 'user_id', but if you have customized the user model this won't be the case. Get the proper name from the configuration. Supersedes #377
Since the introduction of the `SignInGaurd` stack, this method was no longer being called. I moved it's implementation into the failure message used by the `DefaultSignInGuard`. Customizing the message is done entirely via I18n. Resolves #378
Rails will complain if multiple routes are named the same. By using root it was trying to create the root path multiple times. Also a route must provide a controller and an action.
* Add Ruby 2.1 to travis configuration * Update Rails 3.2 and 4.0 appraisals to latest versions * Add I18n.enforce_available_locales setting to test app to avoid deprecation warning. * Add Rails 4.1.0.beta1 to appraisals * Test unit integration feature updated to account for differing test output under rails 4.1 * Update gems
The previous implementation depended on `Clearance.configure` being called in an initializer, otherwise `Clearance.configuration` would be nil. This change makes Clearance work without having to call `Clearance.configure` first. The initializer is now only needed if you want to override a default.
There are many instances where you don't want users to be able to sign up (e.g. admin-only system). Clearance can now disable sign up by setting: Clearance.configure do |config| # other configuration options config.allow_sign_up = false end in `config/initializers/clearance.rb`.
* This clobbers bin/rails and other Rails builtins * We're no longer using `--binstubs` on Rails projects #387
The warnings are coming from inside the codebase!
Sign in guards provide you with fine-grained control over the process of signing in a user. Each guard is run in order and will hand the session off to the next guard in the process. Any guard may also choose to fail the sign in process and provide a message explaining why. Additionally you could immediately determine the sign in process was a success and skip running additional guards.
Also need to update rubygems along with the certs to keep from getting cert errors when bundling. See: http://stackoverflow.com/questions/19150017/ssl-error-when-installing-rubygems-unable-to-pull-data-from-https-rubygems-o
Moving forwards, the lambda used to set the cookie expiration should take a single parameter that will be populated with all available cookies that have been set.
The lambda for `Clearance.configuration.cookie_expiration` can now optionally take an argument. If that argument is present, `session` will call the configured lamdba passing the entire collection of cookies available in session. This allows implementation of remember_me without monkey-patching clearance. Anyone wanting to implement remember_me would now: * add the remember_me checkbox to the login form. * override sessions_controller create to set the remember_me cookie, like so: ``` def create set_remember_me super end private def set_remember_me if params[:remember_me] cookies.permanent[:remember_me] = true else cookies.delete(:remember_me) end end ``` * Configure clearance using something like this: ``` config.cookie_expiration = ->(cookies) do if cookies['remember_me']? 1.year.from_now else nil end end ``` The last two steps could conceivable be extracted to their own gem to make this simpler, if desired.
A helper used to set a custom cookie expiration in specs was not actually yielding, so we weren't actually testing anything. Making the helper yield uncovered a failure. Fixing the failure would have been trivial but I couldn't figure out what its value was, so I simply removed it.
Without strict_mode, EmailValidator allows addresses with unquoted special characters, which can cause SMTP errors when delivery is attempted. Why do we care? If the SMTP errors aren't enough, a user that typos an address by mistakenly inserting a special character is unable to sign in again unless they make the same typo. strict_mode disallows most of these special characters, quoted or not, which seems more appropriate than allowing them. When is the last time you saw an address such as 'first";"email@example.com'.