Mooreds/fix spelling aug 18 2023 (#2474)

* ignore tag files

* fixed typos

* more known words

.github/knownwords.txt

@@ -2868,3 +2868,7 @@ LastPass
 athleisure
 favoriting
 wicking
+SLO
+Bshaffer's
+O'Reilly
+Codemash

.spellcheck.yaml

@@ -2,7 +2,7 @@ matrix:
 - name: Markdown
   sources:
     - '_site/**/*.html|!_site/*at89us2r9qj7kyvrfuntpsp524fe5m*'
-    - 'astro/dist/**/*.html'
+    - 'astro/dist/**/*.html|!astro/dist/blog/tag*'
   default_encoding: utf-8
   spellchecker: hunspell
   dictionary:

astro/src/content/blog/announcing-fusionauth-1-34.mdx

@@ -19,7 +19,7 @@ There are a few things worth calling out.
 
 ## PKCE, PKCE everywhere
 
-[PKCE](https://datatracker.ietf.org/doc/html/rfc7636) is a standard which increases security when used in conjunction with OAuth. It's pronounced ('pixee'). PKCE helps prevent CSRF and authorization code injection attacks. The [security current best practices from the IETF](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics) recommend using PKCE:
+[PKCE](https://datatracker.ietf.org/doc/html/rfc7636) is a standard which increases security when used in conjunction with OAuth. It's pronounced ('pixy'). PKCE helps prevent CSRF and authorization code injection attacks. The [security current best practices from the IETF](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics) recommend using PKCE:
 
 > Clients MUST prevent injection (replay) of authorization codes into the authorization response by attackers.  Public clients MUST use PKCE to this end.  For confidential clients, the use of PKCE is RECOMMENDED.
 

astro/src/content/blog/fusionauth-announces-biotech.mdx

@@ -21,7 +21,7 @@ Per a [recent Microsoft post](https://www.microsoft.com/security/blog/2019/08/20
 
 > By providing an extra barrier and layer of security that makes it incredibly difficult for attackers to get past, MFA can block over 99.9 percent of account compromise attacks. 
 
-But for users, MFA is tedious. You have to set it up. You have to keep track of the additional factor, or rely on built-in services like FaceID and TouchID which require you to trust vendors like Apple and Google.
+But for users, MFA is tedious. You have to set it up. You have to keep track of the additional factor, or rely on built-in services like Face ID and Touch ID which require you to trust vendors like Apple and Google.
 
 ## The solution
 

astro/src/content/blog/single-sign-on-vs-single-log-out.mdx

@@ -68,7 +68,7 @@ Destination="https://idp.example.com/logoutService" ID="_6d0a9a4dbd356e2447b25df
 </samlp:LogoutRequest>
 ```
 
-Here, the `NameID` is "user1@yourdomain.com" and the `SessionIndex` is "_30f323d6-e259-4200-8dc5-4159d6f95fd6". This combination is used to identify the other ongoing sessions. The IdP sends logout requests to the other applications (in this scenario, App2 and App3). Then the other applications send `LogoutResponse` to the IdP.
+Here, the `NameID` is "user1@yourdomain.com" and the `SessionIndex` is `_30f323d6-e259-4200-8dc5-4159d6f95fd6`. This combination is used to identify the other ongoing sessions. The IdP sends logout requests to the other applications (in this scenario, App2 and App3). Then the other applications send `LogoutResponse` to the IdP.
 
 Once the IdP successfully receives the `LogoutResponse` from all the other applications, it sends a `LogoutResponse` to the application from which the user clicked **Logout**. Here, the IdP sends `LogoutResponse` to App1 once the IdP receives `LogoutResponse` from App2 and App3.
 
@@ -99,11 +99,11 @@ In order to secure your application, you should enforce an upper limit for idle
 
 ### Short Session Life
 
-For improved security, you can enforce a short life for each user session. After a designated session time has crossed, the user will have to revalidate the identity to continue with the session. As developers, you can embrace active authentication after each session limit or use [silent authentication](https://developers.xsolla.com/doc/login/authentication-options/silent-authentication/).
+For improved security, you can enforce a short life for each user session. After a designated session time has crossed, the user will have to re-validate the identity to continue with the session. As developers, you can embrace active authentication after each session limit or use [silent authentication](https://developers.xsolla.com/doc/login/authentication-options/silent-authentication/).
 
-### Multifactor Authentication
+### Multi-factor Authentication
 
-[Multifactor authentication (MFA)](/docs/v1/tech/guides/multi-factor-authentication) is not directly involved in the logout flow. However, it's wise to implement this feature for your application at the IdP to improve security. For instance, it adds security to your SLO if you plan to implement automatic termination of idle sessions or short sessions.
+[Multi-factor authentication (MFA)](/docs/v1/tech/guides/multi-factor-authentication) is not directly involved in the logout flow. However, it's wise to implement this feature for your application at the IdP to improve security. For instance, it adds security to your SLO if you plan to implement automatic termination of idle sessions or short sessions.
 
 When implementing multifactor authentication, it's best to use supplementary factors as additional factors for authentication. For example, using a password and fingerprint for authentication is better than using a combination of a password and a PIN. The former combination is better since it relies on two different factors of authentication, namely, a knowledge factor (password) and the inherence factor (fingerprint). The latter combination only relies on two different knowledge factors (password and PIN).