`ActiveSupport::Cache::RedisCacheStore` is not compatible with the
version of Rack Attack we are using (v4.4.1) per
https://github.com/kickstarter/rack-attack/issues/281. Users that had
rate limits enabled might see `Redis::CommandError: ERR value is not an
integer or out of range` because the `raw` parameter wasn't passed along
properly. As a result, the Rack Attack entry would be stored as an
`ActiveSupport::Cache::Entry` instead of a raw string holding an integer
value.

Let's partially revert the change in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30966 to use the
original cache store until we can update to Rack Attack v5.2.3 that has
support for `ActiveSupport::Cache::RedisCacheStore` via
https://github.com/kickstarter/rack-attack/pull/350.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66449

Old cookies are still valid and are automatically
upgraded by Rails

This is the first step in providing a fault-tolerant and distributed
Redis caching store. We disable compression to avoid introducing a
change that could have an adverse effect in production.

Note that we won't be able to take advantage of the fault-tolerance and
distributed features yet until we solve
https://gitlab.com/gitlab-org/gitlab-ce/issues/64829.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/64794

These can contain sensitive content.

None of this code can be reached any more, so it can all be removed

Updates changed method names and fixes spec failures

We use the `Gitlab.ee` and `.ee?` methods in several initializers now.

Simon Knox authored 5 years ago and Enrique Alcántara committed 5 years ago

Use gitlab_ui.scss instead of all the bootstrap imports
Allow the ../node_modules path from gitlab_ui.scss to resolve

This backports the EE changes made to this config file to CE. EE
specific bits do not need an `if Gitlab.ee?`, as everything will work
transparently when using CE.

Jasper Maes authored 6 years ago and Heinrich Lee Yu committed 5 years ago

Model.new.attributes now also returns encrypted attributes.

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>