We're getting one warning when compiling the assets due to the code we
use from font-awesome-sass, and a lot of warnings due to the code we use
from foundation.
Since these warnings are very annoying, and we get them both when
deploying and every time we change an SCSS file in development, we're
silencing them.
I haven't found the way to pass the `quiet_deps` option to the Sprockets
processor, so I'm monkey-patching the Sass engine instead.
This is possible since audited 5.4.3, and IMHO it's useful because
audited has added a callback on touch, which could result in strange
behavior since we might use the `touch` method to expire the cache
without doing any changes.
While this doesn't affect our application because we're using the `on:`
option of the `audited` method in the budget investment model, it'll
make it easier to enable audited for other classes in custom
installations without having to worry about the (usually undesired)
touch callbacks.
We haven't updated this initializer for years, so here's the updated
version. The `expire_auth_token_on_timeout` doesn't seem to exist
anymore, and a few more options have been added.
Note that the default Devise initializer configures
`config.responder.error_status` and `config.responder.redirect_status`
so they follow Hotwire/Turbo conventions. For now, I'm commenting these
lines because we currently don't use Hotwire/Turbo.
We haven't been updating this file for a long time so, and this version
uses the `configure` method instead of the `config` hash.
We're also adding a few comments already included in previous versions
of wicked pdf that we hadn't copied to our initializer.
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.
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 can remove the `new_framework_defaults_6_1` file by using Rails 6.1
default options and overwriting the one we haven't enabled.
We've experienced problems while running the tests (probably the same
would happen on production) when enabling the `has_many_inversing`
option. For example, after creating a legislation answer for a question
with no answers, calling `question.answers_count` would then return `2`
instead of `1`.
So we aren't enabling this option.
This is the default setting in Rails 6.1, and generates an extra tag in
the HTML which tells the browser to download and cache these files as
soon as possible, even before they're needed.
This might not be that relevant in our application, since on most pages
we only generate one CSS and one JS file. But it might make it easier to
move the `javascript_include_tag` statement to the bottom of the page in
the future if we detect that doing so increases performance.
Since we aren't using the old way to handle multiple databases (because
we don't use multiple databases), we can safely enable this option
without breaking anything.
This way user agents will know that the redirection from HTTP to HTTPS
is permanent and not temporary, which is the case if we activate the
`force_ssl` option (which we do by default).
These measures increase protection against CSRF ataks. The only reason
Rails provides them as a configuration option is there are complex
applications that run one version of the code in some servers while
running an old version of the code in other servers might run into
issues because the the old version won't handle the tokens or cookies
generated by the new version.
Since most Consul applications use just one server and the ones with
more servers would only face this issue for a few seconds (while
upgrading to a new version of Consul Democracy), we can safely enable
these configuration options.
Not sure this configuration option does anything, though, since it's
been removed in Rails 7.0 because it was not halting the callbacks.
But, if it does nothing, it's the same as disabling it, which is what we
were doing until now, so in the end using the Rails 6.1 default value
does no harm.
This mostly benefit people using external services, as now there's no
need to query the service to check whether a variant exists.
For most Consul Democracy installations, this will probably not be
relevant, so we're sticking wih the default value.
This patch was added in commit baefc249f because both ViewComponent and
Wicked PDF monkey-patched the `render` method and so they were
incompatible.
However, Rails 6.1 includes the patch used by ViewComponent, meaning
ViewComponent doesn't monkey-patch the `render` method anymore, and so
it's compatible with Wicked PDF.
Note that `Capybara.app_host` now returns `nil` by default and that
breaks tests using `lvh.me` or our custom `app_host` method, so we're
setting `Capybara.app_host` to the value it had in earlier versions of
Rails. I also haven't found a way to remove the code to set the
integration session host in relationable tests which I mentioned in
commit ffc14e499.
Also note that we now filter more parameters, and that they match
regular expressions, so filtering `:passw` means we're filtering
`passwd`, `password`, ...
Note we're excluding a few files:
* Configuration files that weren't generated by us
* Migration files that weren't generated by us
* The Gemfile, since it includes an important comment that must be on
the same line as the gem declaration
* The Budget::Stats class, since the heading statistics are a mess and
having shorter lines would require a lot of refactoring
Quoting `errbit/errbit/blob/main/app/views/apps/_configuration_instructions.html.erb`
> airbrake.io supports various features that are out of scope for Errbit.
This method changed in Globalize version 6.0.1 [1], which we're using since
commit 6072372c9d.
We were getting a deprecation warning in Ruby 2.7:
```
config/initializers/globalize.rb:8: warning: Using the last argument as
keyword parameters is deprecated; maybe ** should be added to the call
```
So we're using the `(...)` arguments syntax to make it compatible with
Ruby 3.0, just like Globalize does when using Ruby 2.7.
[1] See pull request 778 in the globalize/globalize GitHub repo.
This is something we had read about a long time ago, but didn't find how
to reproduce the issue until now.
As mentioned in the Apartment documentation:
> it's important to consider that you may want to maintain the
> "selected" tenant through different parts of the Rack application
> stack. For example, the Devise gem adds the Warden::Manager middleware
> at the end of the stack in the examples above, our
> Apartment::Elevators::Subdomain middleware would come after it.
> Trouble is, Apartment resets the selected tenant after the request is
> finished, so some redirects (e.g. authentication) in Devise will be
> run in the context of the "public" tenant. The same issue would also
> effect a gem such as the better_errors gem which inserts a middleware
> quite early in the Rails middleware stack.
>
> To resolve this issue, consider adding the Apartment middleware at a
> location in the Rack stack that makes sense for your needs, e.g.:
>
> Rails.application.config.middleware.insert_before Warden::Manager,
> Apartment::Elevators::Subdomain
>
> Now work done in the Warden middleware is wrapped in the
> Apartment::Tenant.switch context started in the Generic elevator.
On my machine, seeding a tenant takes about one second, so skipping this
action when it isn't necessary makes tests creating tenants faster
(although creating a tenant still takes about 3-4 seconds on my
machine).
The subdomain elevator we were using, which is included in apartment,
didn't work on hosts already including a subdomain (like
demo.consul.dev, for instance). In those cases, we would manually add
the subdomain to the list of excluded subdomains. Since these subdomains
will be different for different CONSUL installations, it meant each
installation had to customize the code. Furthermore, existing
installations using subdomains would stop working.
So we're using a custom method to find the current tenant, based on the
host defined in `default_url_options`.
In order to avoid any side-effects on single-tenant applications, we're
adding a new configuration option to enable multitenancy
We're enabling two ways to handle this configuration option:
a) Change the application_custom.rb file, which is under version control
b) Change the secrets.yml file, which is not under version control
This way people prefering to handle configuration options through
version control can do so, while people who prefer handling
configuration options through te secrets.yml file can do so as well.
We're also disabling the super-annoying warnings mentioning there are no
tenants which we got every time we run migrations on single-tenant
applications. These messages will only be enabled when the multitenancy
feature is enabled too. For this reason, we're also disabling the
multitenancy feature in the development environment by default.
This way all tenants will be able to access them instead of just the
default one.
The apartment gem recommends using a rake task instead of a migration,
but that's a solution which is primarily meant for new installations.
Migrations are easier to execute on existing installations.
However, since this migration doesn't affect the `schema.rb` file, we
still need to make sure the shared schema is created in tasks which do
not execute migrations, like `db:schema:load` or `db:test:prepare`, just
like the apartment gem recommends. That's why we're enhancing these
tasks so they execute this migration.
Note that there might be cases where the database user isn't a superuser
(as it's usually the case on production environments), meaning commands
to create, alter or drop extensions will fail. There's also the case
where users don't have permissions to create schemas, which is needed in
order to create the shared extensions schema and the schemas used by the
tenants. For these reasons, we're minimizing the number of commands, and
so we only alter or create extensions when it is really necessary.
When users don't have permission, we aren't running the commands but
showing a warning with the steps needed to run the migration manually.
This is only necessary on installations which are going to use
multitenancy; single-tenant applications upgrading don't need to run
this migration, and that's why we aren't raising exceptions when we
can't run it.
For new installations, we'll change the CONSUL installer so extensions
are automatically created in the shared schema.
Also note the plpgsql extension is not handled here. This is a special
extension which must be installed on the pg_catalog schema, which is
always in the search path and so is shared by all tenants.
Finally, we also need to change the `database.yml` file in order to
search for shared extensions while running migrations or model tests,
since none of our enabled extensions are executed during migrations;
we're also adding a rake task for existing installations. Quoting the
apartment documentation:
> your database.yml file must mimic what you've set for your default and
> persistent schemas in Apartment. When you run migrations with Rails,
> it won't know about the extensions schema because Apartment isn't
> injected into the default connection, it's done on a per-request
> basis.
Before this change log generated by OmniAuth was sent to the STDOUT. Now
developers will find those gems log within the `app/log` directory as expected.
Until now, in order to edit an answer, we had to click on its title on
the table and then on the "Edit answer" link.
That was tedious and different from what we usually do in the admin
section. Furthermore, the code for the answers table was written twice
and when we modified it we forgot to update the one in the `show`
action, meaning the table here provided less information than the
information present in the answers tables.
Co-Authored-By: Javi Martín <javim@elretirao.net>
This method was introduced in Rails 6.0. It can be used to take an array
and create a hash where the elements of the array are the indexes of the
hash.
We can remove the `new_framework_defaults_6_0` file by using Rails 6.0
default options and overwriting the ones we haven't enabled.
We're still using the classic autoloader because we still haven't
checked how switching to zeitwerk will affect the way CONSUL
installations customize their code.
And we're using the default queues for Active Storage because we were
already using them and that will be the default option in Rails 6.1.
Similar to the way we enabled cache versioning in commit e01a94d7b. This
only affects caching `ActiveRecord::Relation` objects. I'm not even sure
we cache these objects, though, so we're just enabling the option
because it's the default one in Rails 6.0.
