Fix invalid book.project.title

topics/oidc/java/adapter-context.adoc

@@ -1,7 +1,7 @@
 === Security Context
 
 The `KeycloakSecurityContext` interface is available if you need to access to the tokens directly. This could be useful if you want to retrieve additional
-details from the token (such as user profile information) or you want to invoke a RESTful service that is protected by {{book.project.title}}.
+details from the token (such as user profile information) or you want to invoke a RESTful service that is protected by {{book.project.name}}.
 
 In servlet environments it is available in secured invocations as an attribute in HttpServletRequest:
 [source,java]

topics/oidc/java/adapter_error_handling.adoc

@@ -3,9 +3,9 @@
 === Error Handling
 
 {{book.project.name}} has some error handling facilities for servlet based client adapters.
-When an error is encountered in authentication, {{book.project.title}} will call `HttpServletResponse.sendError()`.
+When an error is encountered in authentication, {{book.project.name}} will call `HttpServletResponse.sendError()`.
 You can set up an error-page within your `web.xml` file to handle the error however you want.
-{{book.project.title}} may throw 400, 401, 403, and 500 errors.
+{{book.project.name}} may throw 400, 401, 403, and 500 errors.
 
 [source,xml]
 ----

topics/oidc/java/jboss-adapter.adoc

@@ -233,10 +233,10 @@ Here's an example:
 
 ==== Securing WARs via Keycloak Subsystem
 
-You do not have to modify your WAR to secure it with {{book.project.title}}. Instead you can externally secure it via the {{book.project.title}} Adapter Subsystem.
+You do not have to modify your WAR to secure it with {{book.project.name}}. Instead you can externally secure it via the {{book.project.name}} Adapter Subsystem.
 While you don't have to specify KEYCLOAK as an `auth-method`, you still have to define the `security-constraints` in `web.xml`.
 You do not, however, have to create a `WEB-INF/keycloak.json` file.
-This metadata is instead defined within server configuration (i.e. `standalone.xml`) in the {{book.project.title}} subsystem definition.
+This metadata is instead defined within server configuration (i.e. `standalone.xml`) in the {{book.project.name}} subsystem definition.
 
 [source,xml]
 ----
@@ -265,7 +265,7 @@ The rest of the configuration corresponds pretty much one to one with the `keycl
 
 The exception is the `credential` element. 
 
-To make it easier for you, you can go to the {{book.project.title}} Administration Console and go to the Application/Installation tab of the application this WAR is aligned with.
+To make it easier for you, you can go to the {{book.project.name}} Administration Console and go to the Application/Installation tab of the application this WAR is aligned with.
 It provides an example XML file you can cut and paste. 
 
 There is an additional convenience format for this XML if you have multiple WARs you are deployment that are secured by the same domain.

topics/oidc/java/servlet-filter-adapter.adoc

@@ -1,9 +1,9 @@
 [[_servlet_filter_adapter]]
 === Java Servlet Filter Adapter
 
-If you are deploying your Java Servlet application on a platform where there is no {{book.project.title}} adapter you opt to use the servlet filter adapter.
+If you are deploying your Java Servlet application on a platform where there is no {{book.project.name}} adapter you opt to use the servlet filter adapter.
 This adapter works a bit differently than the other adapters. You do not define security constraints in web.xml.
-Instead you define a filter mapping using the {{book.project.title}} servlet filter adapter to secure the url patterns you want to secure.
+Instead you define a filter mapping using the {{book.project.name}} servlet filter adapter to secure the url patterns you want to secure.
 
 WARNING: Backchannel logout works a bit differently than the standard adapters.
 Instead of invalidating the HTTP session it marks the session id as logged out.
@@ -31,14 +31,14 @@ There's no way standard way to invalidate an HTTP session based on a session id.
 ----
 
 In the snippet above there are two url-patterns.
- _/protected/*_ are the files we want protected, while the _/keycloak/*_ url-pattern handles callbacks from the {{book.project.title}} server.
+ _/protected/*_ are the files we want protected, while the _/keycloak/*_ url-pattern handles callbacks from the {{book.project.name}} server.
 
-Note that you should configure your client in the {{book.project.title}} Admin Console with an Admin URL that points to a secured section covered by the filter's url-pattern.
+Note that you should configure your client in the {{book.project.name}} Admin Console with an Admin URL that points to a secured section covered by the filter's url-pattern.
 
 The Admin URL will make callbacks to the Admin URL to do things like backchannel logout.
 So, the Admin URL in this example should be `http[s]://hostname/{context-root}/keycloak`.
 
-The {{book.project.title}} filter has the same configuration parameters as the other adapters except you must define them as filter init params instead of context params.
+The {{book.project.name}} filter has the same configuration parameters as the other adapters except you must define them as filter init params instead of context params.
 
 To use this filter, include this maven artifact in your WAR poms:
 

topics/overview/supported-platforms.adoc

@@ -26,8 +26,8 @@
 
 {% if book.community %}
 ==== Node.js
-* https://github.com/keycloak/keycloak-nodejs-connect[{{book.project.title}} Connect] (community)
+* https://github.com/keycloak/keycloak-nodejs-connect[{{book.project.name}} Connect] (community)
-* https://github.com/keycloak/keycloak-nodejs-connect[{{book.project.title}} Auth Utils] (community)
+* https://github.com/keycloak/keycloak-nodejs-connect[{{book.project.name}} Auth Utils] (community)
 {% endif %}
 
 {% if book.community %}