keystone/doc/source/admin/url-safe-naming.inc
Andreas Jaeger f10f95b455 Docs: Make robust with using real links
Our tools noticed that keystone links to
https://docs.openstack.org/keystone/latest/admin/identity-domain-specific-config.html
which does not exist anymore.

The page was removed but the link to it was not changed. Replace this
and similar links with internal links that will work even if files are
moved - and can be verified, thus sphinx will error in case of broken
targets.

These changes include a few other fixes for broken keystone links, e.g.
to renamed anchors.

For the include files in admin/configuration.rst and
admin/federation/configure_federation.rst: Rename them to *inc.
The files were
published twice (as separate files and on this page) and thus
referencing failed. Renaming avoids this.

Also, put doctree outside of html tree so that it does not get
published.

Change-Id: I3d07637b0046cc88a66bcb51a0a4fe7c146c1549
2019-08-09 20:15:14 +02:00

34 lines
1.5 KiB
ReStructuredText

.. -*- rst -*-
URL safe naming of projects and domains
=======================================
In the future, keystone may offer the ability to identify a project in a
hierarchy via a URL style of naming from the root of the hierarchy (for example
specifying 'projectA/projectB/projectC' as the project name in an
authentication request). In order to prepare for this, keystone supports the
optional ability to ensure both projects and domains are named without
including any of the reserved characters specified in section 2.2 of
`rfc3986 <http://tools.ietf.org/html/rfc3986>`_.
The safety of the names of projects and domains can be controlled via two
configuration options:
.. code-block:: ini
[resource]
project_name_url_safe = off
domain_name_url_safe = off
When set to ``off`` (which is the default), no checking is done on the URL
safeness of names. When set to ``new``, an attempt to create a new project or
domain with an unsafe name (or update the name of a project or domain to be
unsafe) will cause a status code of 400 (Bad Request) to be returned. Setting
the configuration option to ``strict`` will, in addition to preventing the
creation and updating of entities with unsafe names, cause an authentication
attempt which specifies a project or domain name that is unsafe to return a
status code of 401 (Unauthorized).
It is recommended that installations take the steps necessary to where they
can run with both options set to ``strict`` as soon as is practical.