Typos

doc/sources/admin/adaptativeauthenticationlevel.rst

@@ -4,7 +4,7 @@ Adaptative Authentication Level
 Presentation
 ------------
 
-A user obtain an authentication level depending on which authentication
+A user reaches an authentication level depending on which authentication
 module was used, and eventually which second factor module.
 
 This plugin allows to adapt this authentication level depending on
@@ -23,7 +23,7 @@ they would then not be forced to use 2FA to access the strategic application.
 Configuration
 -------------
 
-This plugin is enabled when at least one rule is defind.
+This plugin is enabled when at least one rule is defined.
 
 To configure rules, go in ``General Parameters`` > ``Plugins`` >
 ``Adapative Authentication Level``.

doc/sources/admin/cli_examples.rst

@@ -195,13 +195,13 @@ In this example we have:
 Configure form replay
 ---------------------
 
-To add form replay on a host, you need to set the catched URI and
+To add form replay on a host, you need to set the caught URI and
 the variables to post.
 
 In this example we have:
 
 - Host: test.example.com
-- Catched URI: /login.php
+- Caught URI: /login.php
 - jQuery URL: default
 
 - Variables:

doc/sources/admin/configvhost.rst

@@ -454,6 +454,26 @@ A virtual host contains:
 -  POST data: use form replay
 -  Options: redirection port, protocol, Handler type, aliases,required authentication level,...
 
+Wildcards in hostnames
+----------------------
+
+|image0| Since 2.0, a wildcard can be used in virtualhost name (not in
+aliases !): ``*.example.com`` matches all hostnames that belong to
+``example.com`` domain. Version 2.0.9 improves this and allows better
+wildcards such as ``test-*.example.com`` or ``test-%.example.com``. The
+``%`` wilcard doesn't match subdomains.
+
+Even if a wildcard exists, if a VirtualHost is explicitly declared, this
+rule will be applied. Example with precedence order for test.sub.example.com:
+
+#. test.sub.example.com
+#. test%.sub.example.com
+#. test*.sub.example.com
+#. %.sub.example.com
+#. \*.sub.example.com
+#. \*.example.com (``%.example.com`` does not match
+   test.sub.example.com)
+
 Access rules and HTTP headers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -574,3 +594,6 @@ Some options are available:
 "Port" and "HTTPS" options are used to build redirection URL *(when user
 is not logged, or for CDA requests)*. By default, default values are
 used. These options are only here to override default values.
+
+.. |image1| image:: /documentation/new.png
+   :width: 35px

doc/sources/admin/presentation.rst

@@ -76,29 +76,22 @@ Login
 
 |image1|
 
-#. User tries to access protected application, his request is catched by
-   Handler
-#. :doc:`SSO cookies<ssocookie>` is not
-   detected, so Handler redirects user to Portal
+#. User tries to access a protected application, his request is caught by Handler
+#. :doc:`SSO cookie<ssocookie>` is not detected, so Handler redirects user to Portal
 #. User authenticates on Portal
 #. Portal checks authentication
-#. If authentication succeed, Portal collect user data
+#. If authentication succeeds, Portal collects user data
 #. Portal creates a session to store user data
-#. Portal gets the session key
-#. Portal creates
-   :doc:`SSO cookies<ssocookie>` with
-   session key as value
-#. User is redirected on protected application, with his new cookie
-#. Handler reads session key from cookie and retrieves user session
-   datas
-#. Handler stores user datas in its cache
-#. Handler check access rule and send headers to protected application
+#. Portal gets the session Id
+#. Portal creates :doc:`SSO cookie<ssocookie>` with the session Id as value
+#. User is redirected on protected application, with a SSO cookie
+#. Handler reads session Id from the cookie and retrieves user session data
+#. Handler stores user data in its cache
+#. Handler checks access rules and sends headers to the protected application
 #. Protected application sends response to Handler
-#. Handler forwards the response to user
+#. Handler forwards the response to the user
 
-Then handler will check
-:doc:`SSO cookies<ssocookie>` for each
-HTTP request.
+Then handler will check :doc:`SSO cookies<ssocookie>` for each HTTP request.
 
 Logout
 ~~~~~~
@@ -108,9 +101,7 @@ Default use case:
 #. User clicks on the logout link in Portal
 #. Portal destroys session and redirects user on itself with an empty
    :doc:`SSO cookies<ssocookie>`
-#. User is redirected on portal and his
-   :doc:`SSO cookies<ssocookie>` is
-   empty
+#. User is redirected on portal and his :doc:`SSO cookies<ssocookie>` is empty
 
 LemonLDAP::NG is also able to
 :doc:`catch logout request<writingrulesand_headers>`

doc/sources/admin/webserviceprotection.rst

@@ -44,7 +44,7 @@ For example:
 
    curl \
      -H "Authorization: Bearer a74d504ec9e784785e70a1da2b95d1d2" \
-     https://auth.example.ccom/oauth2/userinfo | json_pp
+     https://auth.example.com/oauth2/userinfo | json_pp
 
 .. code-block:: javascript