There are many possible ways to implement this feature:
* Adding a custom middleware
* Using rack-attack with a blocklist
* Using routes constraints
We're choosing to use a controller concern with a redirect because it's
what we do to handle unauthorized cancancan exceptions.
The keys to configure Omniauth for WordPress were only added
to the production environment, so we unified all the keys across
the staging and preproduction environments.
This will allow us to keep using the timezone used when running
the installer.
We keep using Madrid as default timezone in the installer and in
the application.
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 comply with the security measure for the
ENS: "[op.acc.5.r5.2] The user shall be informed of
the last access made with his identity".
We have added a new secret to display the last
access made to the user on the "My account" page.
Note we don't need to update the tests; the tests themselves help us
confirm that `Rails.application.secrets` and `Tenant.current_secrets`
return the same object on single-tenant applications.
Right now this is configured using the `secrets.yml` file, which is the
file we've used in the past to configure SMTP settings.
Note that, in the `current_secrets` method, the `if default?` condition
is there so in single-tenant applications it returns the exact same
object as `Rails.application.secrets`, and it makes it immediately clear
for developers reading the code. We're also caching the tenant secrets
(using `||=`) so they behave the same way as Rails secrets; for this to
work properly 100% of the time (for example, in tests) we need to expire
these cached secrets whenever the Rails secrets change.
A similar `unless Tenant.default?` condition is present in the
ApplicationMailer because there's a chance some CONSUL installations
might not be using secrets to define the SMTP settings(they might be
using environment variables, for example) and so in this case we don't
want to force settings based on the secrets.yml file because it would
break the application.
The structure of the SMTP settings in the secrets file should be:
```
production:
tenants:
name_of_the_tenant_subdomain:
smtp_settings:
address:
(...)
```
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.
We already support Errbit and Airbrake as error monitoring services.
Since some people might not want to setup Errbit and might prefer
Rollbar over Airbrake, we're referencing it in the custom gemfile.
Although our installer automatically generates a secret key base, we
want to avoid any chance of installations who don't use the installer
having an empty secret key base or using the default secret key base we
provide to use on development and test environments.
With Errbit, you can set up your own server and host the information
regarding your exceptions there. You can also hire Airbrake's hosting
services or easily setup Errbit on Heroku.
We're still including the rollbar gem so we don't harm CONSUL users who
are using rollbar.
Note Errbit requires an old version of Airbrake which forced users to
configure the gem. So we're adding the current environtment to
`ignore_environments` when the project id isn't defined; this way the
application won't crash in this case.
While this is not a secret and in theory should be in a file under
version control, currently the CONSUL installer disables delayed jobs by
default, meaning we were keeping two versions of the delayed jobs
configuration file, and some existing configurations have their settings
defined in a file in capistrano's `shared` folder.
So we're moving existing settings to the secrets file.
this is usually configured in the production.rb file (which is under
version control), the natural place to configure it is the secrets.yml
file.
Until now we were using the capistrano shared folder, but that's a bit
inconvenient since changes we've done to the production.rb file (like
changing eager_load_paths when we upgraded to Rails 5) won't take effect
after a deployment.
Since SMTP passwords should not be in a file under version control, and
they're usually configured in the production.rb file (which is under
version control), the natural place to configure it is the secrets.yml
file.
Until now we were using the capistrano shared folder, but that's a bit
inconvenient since changes we've done to the production.rb file (like
changing eager_load_paths when we upgraded to Rails 5) won't take effect
after a deployment.
Why:
* Crowdin now hosts all consul translations publicly so anyone can contribute https://crowdin.com/project/consul/invite
* Crowdin makes easy for non-tech people to contribute, once we have a demo site we'll be able to offer "on site" translation
* If you still use Tolk, we recommend removing this commit (but adding tolk gem to ./Gemfile_custom file to avoid future merge conflicts)
How:
* Reverting changes introduced with 9610a6a933
