Closes https://github.com/varvet/pundit/pull/711 (original issue and pull request)
> A01:2021-Broken Access Control is the category with the most serious web
application security risk.
>
> Using scope.all in templates violates the principle of least privilege
or deny by default, where access should only be granted for particular
capabilities, roles, or users.
>
> This change improves the security of default templates
>
> Ref: https://owasp.org/Top10/A01_2021-Broken_Access_Control/
— by @tagliala (github.com/tagliala)
Co-authored-by: Duncan Stuart <dgmstuart@gmail.com>
Coverage gets generated on every build, but we only need to send it for
one build. Send it on the first one, otherwise we get eg:
./cc-test-reporter after-build --exit-code $TRAVIS_TEST_RESULT
time="2019-08-22T12:37:01Z" level=warning msg="Conflict when uploading: A test report for commit 6dabaaa6cd7e4c5c51dc538e4fbb7861ca433d8e already exists, skipping upload"
I guess this is because the test reporter assumes that if coverage
exists, then it has been sent?
Config from here:
https://docs.codeclimate.com/docs/travis-ci-test-coverage#section-travis-ci-single-test-suite-non-parallel-builds
I couldn't work out if it's officially unsupported, but RSpec3 came out
around 5 years ago and we had a fair amount of code which seemed to
only be there to support it.
Now that we don't need to support Ruby 2.1 or 2.2, we can use the latest
version of Rubocop (which dropped support for those versions).
Also remove things from Rubocop which are now defaults:
- FrozenStringLiteralComment is now on by default
- DisplayCopNames used to be off by default but now seems to be on
- This project doesn't seem to have ever had gemfiles or vendor
directories - my guess is that this was a copy-paste from another
project.
This is enabled by default in later versions of Rubocop. Making this
change now removes this conflict for people running later versions.
Automatically fixed with `rubocop -a`
This commit does two things:
1. Move development dependencies back to gemspec
2. Restrict versions of some gems
It should also be noted that the recommendation is to commit
Gemfile.lock, however in this case it is not possible to do so:
3. Why we don't commit Gemfile.lock
Each of these requires a more detailed discussion:
1. Move development dependencies back to gemspec
9691355 originally moved all these dependencies into the Gemfile:
https://github.com/varvet/pundit/pull/435
The recommendation in the docs seems to be to use the gemspec for
development dependencies:
https://bundler.io/guides/creating_gem.html#getting-started
2. Restrict versions of some gems
While we want to be as flexible as possible with the gem's production
dependencies, we need to be more specific with our development
dependencies. In particular gems developed against one version of
Rubocop cannot be expected to work with later versions, since Rubocop
adds and renames cops in new versions.
In particular version 0.70.0 renames a cop which we are specifying,
resulting in the following errors.
.rubocop.yml:81: `Style/TrivialAccessors` is concealed by line 96
Error: The `Layout/IndentHash` cop has been renamed to `Layout/IndentFirstHashElement`.
(obsolete configuration found in .rubocop.yml, please update it)
Rubocop version 0.67.2 passes without issues on the latest ruby version,
but is incompatible with 2.2.x and earlier. 0.57.2 is the latest version
which works everywhere.
Note that when running `gem build pundit.gemspec` we get warnings about
some open-ended dependencies:
WARNING: open-ended dependency on activesupport (>= 3.0.0) is not recommended
if activesupport is semantically versioned, use:
add_runtime_dependency 'activesupport', '~> 3.0', '>= 3.0.0'
However, I feel OK about these being loose, and since this gem is not so
often maintained, I'd prefer not to place an upper limit on the
runtime_dependency. The other gems with open-ended dependencies are also
part of Rails, so I believe they'll need to be the same version as
activesupport, which is why they have the same version constraint.
For the gems where we don't specify any version constraint we also get
this warning. For most of these (eg. pry) we genuinely don't care what
version is used.
3. Why we don't commit Gemfile.lock
When this gem was created the standard practice was to gitignore the
Gemfile.lock, but the guidance has changed:
> When Bundler first shipped, the Gemfile.lock was included in the
> .gitignore file included with generated gems. Over time, however, it
> became clear that this practice forces the pain of broken dependencies
> onto new contributors, while leaving existing contributors potentially
> unaware of the problem. Since bundle install is usually the first step
> towards a contribution, the pain of broken dependencies would
> discourage new contributors from contributing. As a result, we have
> revised our guidance for gem authors to now recommend checking in the
> lock for gems.
https://bundler.io/man/bundle-install.1.html#THE-GEMFILE-LOCK
The intention is that by committing the Gemfile.lock we ensure that all
developers of this gem have the same dependencies.
HOWEVER, we are currently supporting ruby 2.1 and 2.2. Newer versions of
some gems (eg. i18n, which is required by activesupport) are only
compatible with ruby 2.3 and up, so a lockfile compatible with the
latest version of activesupport (which is a runtime dependency) will not
be compatible with these versions.
The impact of this is that we can't commit the lockfile without also
dropping support for versions 2.1 and 2.2.
* CI against Ruby 2.2.8/2.3.5/2.4.2
* Remove unnecessary magic comments with ruby 2.0 or later
* Change `TargetRubyVersion` to 2.0
ruby 1.9.3 has already been dropped by 0569b065d7
* Change `TargetRubyVersion` to 2.1
* Drop jruby1.7 on Travis
Kim Burgestrand