Adds enum certificate_source to pages_domains table
with default manually_uploaded
Mark certificates as 'gitlab_provided'
if the were obtained through Let's Encrypt
Mark certificates as 'user_provided' if they were uploaded through
controller or api
Only show private key in domain edit form if it is 'user_provided'
Only show LetsEncrypt option if is enabled by application settings
(and feature flag)
Refactor and fix some specs to match new logic
Don't show Let's Encrypt certificates as well
Updates specs to use new rails5 format.
The old format:
`get :show, { some: params }, { some: headers }`
The new format:
`get :show, params: { some: params }, headers: { some: headers }`
* Regards project-level pages config
- Nav link is now shown only if Pages is enabled for instance
- Navigation to following controllers denied if Pages disabled:
* projects/pages_controller
* projects/pages_domains_controller
- 'disabled' partial removed
+ Test for pages_controller introduced
==================
= Implementation =
==================
1. The path of the page is of the form 'group/project/pages/domains/<domain_name>'
2. Rails looks at `params[:id]` (which should be the domain name), and finds the
relevant model record.
3. Given a domain like `foo.bar`, Rails sets `params[:id]` to `foo` (should be
`foo.bar`), and sets `params[:format]` to `bar`
4. This commit fixes the issue by adding a route constraint, so that
`params[:id]` is set to the entire `foo.bar` domain name.
=========
= Tests =
=========
1. Add controller specs for the `PagesDomainController`. These are
slightly orthogonal to this bug fix (they don't fail when this bug is
present), but should be present nonetheless.
2. Add routing specs that catch this bug (by asserting that the `id`
param is passed as expected when it contains a domain name).
3. Modify the 'RESTful project resources' routing spec shared example to
accomodate controllers where the controller path (such as
`pages/domains`) is different from the controller name (such as
`pages_domains`).