Replaces Javascript by JavaScript

topics/clients/client-oidc.adoc

@@ -2,7 +2,7 @@
 === OIDC Clients
 
 <<fake/../../sso-protocols/oidc.adoc#_oidc,OpenID Connect>> is the preferred protocol to secure applications.  It was designed from the ground up to be web friendly
-and works best with HTML5/Javascript applications.
+and works best with HTML5/JavaScript applications.
 
 To create a OIDC client go to the `Clients` left menu item.  On this page you'll see a `create` button on the right.
 
@@ -61,7 +61,7 @@ _confidential_::
   Confidential access type is for clients that need to perform a browser login and that you want to require a client secret when they turn an access code into an access token,
   (see http://tools.ietf.org/html/rfc6749#section-4.1.3[Access Token Request] in the OAuth 2.0 spec for more details).  The advantages of this is that it is a little extra security.
   Since {{book.project.name}} requires you to register valid redirect-uris, we're not exactly sure what this little extra security is though.
-  :) The disadvantages of this access type is that confidential access type is pointless for pure Javascript clients as anybody could easily figure out your client's secret!
+  :) The disadvantages of this access type is that confidential access type is pointless for pure JavaScript clients as anybody could easily figure out your client's secret!
 
 _public_::
   Public access type is for clients that need to perform a browser login and that you feel that the added extra security of confidential access type is not needed.
@@ -114,10 +114,10 @@ See link:{{book.adapterguide.link}}[{{book.adapterguide.name}}] for more informa
 *Web Origins*
 
 This option centers around link:http://www.w3.org/TR/cors/[CORS] which stands for Cross-Origin Resource Sharing.
-If executing browser Javascript tries to make an AJAX HTTP request to a server whose domain is different than the one the
-Javascript code came from, then the request uses the CORS.
+If executing browser JavaScript tries to make an AJAX HTTP request to a server whose domain is different than the one the
+JavaScript code came from, then the request uses the CORS.
 The server must handle CORS requests in a special way, otherwise the browser will not display or allow the request to be processed.
-This protocol exists to protect against XSS, CSRF and other Javascript-based attacks.
+This protocol exists to protect against XSS, CSRF and other JavaScript-based attacks.
 
 {{book.project.name}} has support for validated CORS requests.  The way it works is that the domains listed in the
 `Web Origins` setting for the client are embedded within the access token sent to the client application.  The client

topics/overview/features.adoc

@@ -31,7 +31,7 @@
   into a OIDC ID Token, Access Token, SAML attribute statements, etc.  This feature allows you to basically
   tailor how you want auth responses to look.
 * Can support any platform that has an Open ID Connect or SAML 2.0 client adapter.  {{book.project.name}} does provide
-  client adapters for Pure HTML5/Javascript apps, JBoss AS7, JBoss EAP 6.x, JBoss EAP 7, Wildfly, Tomcat 7,
+  client adapters for Pure HTML5/JavaScript apps, JBoss AS7, JBoss EAP 6.x, JBoss EAP 7, Wildfly, Tomcat 7,
   Tomcat 8, Jetty 9.1.x, Jetty 9.2.x, and Jetty 8.1.x.
 * Tons of SPIs for customizing every aspect of the server.
 

topics/sso-protocols/oidc.adoc

@@ -53,9 +53,9 @@ has revoked access.  This makes things more secure and more scalable.
 Another important aspect of this flow is the concept of a _public_ vs. a _confidential_ client.  _Confidential_ clients are required
 to provide a client secret when they exchange the temporary codes for tokens.  _Public_ clients are not required to provide this client secret.
 _Public_ clients are perfectly fine so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the
-client.  HTML5/Javascript clients actually always have to be _public_ clients because there is no way to transmit the client secret to them in a secure
+client.  HTML5/JavaScript clients actually always have to be _public_ clients because there is no way to transmit the client secret to them in a secure
 manner.  Again, this is ok so long as you use HTTPS and strictly enforce redirect URI registration.  This guide goes more detail
-into this in the 
+into this in the
 
 // DOCS REMARK: Please update the cross-reference as it does not resolve correctly. <<fake/../../client.adoc,Client>> chapter.
 

topics/sso-protocols/saml-vs-oidc.adoc

@@ -7,12 +7,12 @@ SAML tends to be a bit more verbose than OIDC.
 
 Beyond verbosity of exchanged data, if you compare the specifications you'll find that OIDC was designed to work with the
 web while SAML was retrofitted to work on top of the web.  For example,
-OIDC is also much better suited for HTML5/Javascript applications because it is
+OIDC is also much better suited for HTML5/JavaScript applications because it is
 much much simpler to implement on the client side than SAML.  Since tokens are in the JSON format,
-they can be directly consumed by Javascript.  Also, you'll find many nice little switches and features that
+they can be directly consumed by JavaScript.  Also, you'll find many nice little switches and features that
 make implementing security in your web applications easier.  For example, check out the iframe trick that the specification
 uses to easily determine if a user is still logged in or not.
 
 SAML has its uses though.  As you see the OIDC specifications evolve you see they implement more and more features that
 SAML has had for years.  What we often see is that people pick SAML over OIDC because of the perception that it is more mature
-and also because they already have existing applications that are secured by it.
+and also because they already have existing applications that are secured by it.

topics/threat/csrf.adoc

@@ -8,7 +8,7 @@ These attacks are mitigated by matching a state cookie against a posted form or
 OAuth 2.0 login specification requires that a state cookie be used and matched against a transmitted state parameter.
 {{book.project.name}} fully implements this part of the specification so all logins are protected.
 
-The {{book.project.name}} Admin Console is a pure Javascript/HTML5 application that makes REST calls to the backend {{book.project.name}} admin REST API.
+The {{book.project.name}} Admin Console is a pure JavaScript/HTML5 application that makes REST calls to the backend {{book.project.name}} admin REST API.
 These calls all require bearer token authentication and are made via JavaScript Ajax calls.
 CSRF does not apply here.
 The admin REST API can also be configured to validate the CORS origins as well.