This way only verified users will be able to access this page, which
shows the username of the receiver of the direct message. With this,
it's no longer possible for unverified users to browse direct message
URLs in order to collect usernames from every user.
As Rails does with the application log and other tools. We
are going to use the same filtering rules we use in Consul Democracy.
We are renaming the initializer file name `filter_parameter_logging.rb` so
it's loaded before the errbit initializer.
As this secret is currently not programmed to be customisable for each Tenant,
we take it out of the security section. The reason is that so far everything inside this security section can be overwritten per tenant. With this change we are trying
to prevent anyone from trying to overwrite it on a per Tenant basis, as it would have
no effect.
In order to test that we remove metadata from PDF we need add
"pdf-reader" gem.
With this gem we can check the info from the PDF and ensure that
this info is removed.
In order to remove metadata from PDF documents we will use the
exiftool_vendored gem.
The following line:
Exiftool.new(attachment_path, "-overwrite_original -all:all=")
Overwrites the original file with another file without metadata.
So far this is the best solution we have found to perform this
metadata deletion.
When using Exiftool an exception is thrown, so we added a rescue
to handle it. Here is a task created where this problem is discussed
in issue 28 in the https://github.com/exiftool-rb/exiftool.rb/ repository.
We'll wait to see if this will be fixed in future versions.
Bumps [rubocop-rails](https://github.com/rubocop/rubocop-rails) from 2.20.2 to 2.21.2.
- [Release notes](https://github.com/rubocop/rubocop-rails/releases)
- [Changelog](https://github.com/rubocop/rubocop-rails/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rubocop/rubocop-rails/compare/v2.20.2...v2.21.2)
---
updated-dependencies:
- dependency-name: rubocop-rails
dependency-type: direct:development
update-type: version-update:semver-minor
...
Note version 2.21.0 relaxes the default `Include` path for
`Rails/FindEach`, and so this version can find and correct offenses
outside the `app/models/` folder [1].
Also note this version replaces `unless something.include?` with `if
something.exclude?`; since we don't use the `exclude?` method anywhere,
we're removing the `include?` method from the list of methods checked by
this cop.
Finally, the Rails/HttpStatus method now returns a false positive when
rendering a dashboard partial and passing the `status` variable. In
order to avoid this issue, we could change the name of the local
variable or move the partial to a component, but for now we're simply
excluding these files for this cop.
[1] https://github.com/rubocop/rubocop-rails/pull/1059/commits/0066b3505
Signed-off-by: dependabot[bot] <support@github.com>
This rule was added in rubocop-capybara 2.19.0. We were following it
about 85% of the time.
Now we won't have to check both have_css and have_selector when
searching the code.
Puma 4 is no longer maintained, and Puma 5 removed the option to run
Puma as as daemon. That means that, in order to upgrade, we need to rely
in a process monitoring tool. We're using systemd because it's installed
by default in most (all?) operating systems running Consul Democracy on
production and it's supported by both Puma and the capistrano3-puma gem.
Using systemd means Puma will be automatically started whenever it
crashes, so we no longer need the changes done in commit 40b3c9f2c and
we can now use the default tasks configuration in capistrano3-puma and
capistrano3-delayed-job.
Since Puma is also started automatically when booting the system, we
don't need a cron job to do so anymore and can remove it from the
`schedule.rb` file.
RSpec/FilePath is deprecated since rubocop-rspec 2.24.0 and will be
removed in rubocop-rspec 3.0 in favor of RSpec/SpecFilePathFormat and
RSpec/SpecFilePathSuffix.
In order to the display a warn text on the last attempt
before the account is locked, we need update
config.paranoid to false as the devise documentation
explains.
Adding "config.paranoid: false" implies further changes
to the code, so for now we unncomment the default value
"config.last_attempt_warning = true" and update it to false.
As it seems that adding complexity to the password is something that
might be wanted from the Consul applications, we added the necessary
changes to allow it.
In this version we simply:
- Uncomment the configuration variable "password_complexity"
- Set this variable without any restrictions
- Adapt the application so that everything still works normally.
One of the things that had to be done to adapt the application
was to remove the overwriting of the "self.included" method.
The original idea of overwriting the "self.included" method seems
to be the possibility of being able to overwrite the
:current_equal_password_validation validation.
The problem comes from the fact that by only calling that validation,
the rest of the validations that are defined (in this case
"password_complexity") are no longer applied.
It seems like a good idea to remove the overwrite of the "self.included"
method to allow all the defined validations to be applied and simply
overwrite the :current_equal_password_validation method so that
everything behaves the same.
:allow_passwords_equal_to_email configuration has been enabled too,
in order to allow existing records with this configuration.
Another change made was to uncomment the line:
and to keep everything working the same set the value to false:
config.email_validation = false.
This change has had to be made because in the documentation of
devise-security it says the following:
In other words, if we want to use the :secure_validatable module
we have to enable this configuration even if its value is "false".
If we kept the configuration variable commented out:
The following error appears:
"uninitialized constant Devise::Models::SecureValidatable::EmailValidator".
So it has been verified that if before making any change we
decommented the line and added the value of "false", the application
worked as normal.
In these commits ffe9ac70d8def3 we updated the devise-security version.
In these versions the 'password_regex' configuration key and some comments
were changed.
We update this file in order to use the new configuration key 'password_complexity' and keep comments updated.
We were already opening them in the same window because we were
accidentall sanitizing the `target` attribute, but now we're making the
point more explicit.
