Fix minor typos in the 'Server Developer' guide (#1702)

server_development/topics/action-token-handler-spi.adoc

@@ -160,7 +160,7 @@ token, only the last token would be invalidated. In that case, you should use
 `org.keycloak.models.SingleUseObjectProvider` in action token handler to invalidate the used tokens manually.
 +
 Default implementation of most of the `ActionTokenHandler` methods is the
-`org.keycloak.authentication.actiontoken.AbstractActionTokenHander` abstract class in `keycloak-services` module. The
+`org.keycloak.authentication.actiontoken.AbstractActionTokenHandler` abstract class in `keycloak-services` module. The
 only method that needs to be implemented is `handleToken(token, context)` that performs the actual action.
 
  *  `org.keycloak.authentication.actiontoken.ActionTokenHandlerFactory` - factory that instantiates action token

server_development/topics/auth-spi.adoc

@@ -10,7 +10,7 @@ The Admin Console supports applying, ordering, and configuring these new mechani
 Different aspects of this form can be enabled and disabled for example
 Recaptcha support can be turned off and on.
 The same authentication SPI can be used to add another page to the registration flow or reimplement it entirely.
-There's also an additional fine-grained SPI you can use to add specific validations and user extensions to the built in registration form.
+There's also an additional fine-grained SPI you can use to add specific validations and user extensions to the built-in registration form.
 
 A required action in {project_name} is an action that a user has to perform after he authenticates.
 After the action is performed successfully, the user doesn't have to perform the action again.
@@ -700,7 +700,7 @@ public class SecretQuestionAuthenticatorFactory implements AuthenticatorFactory,
 The next thing the factory is responsible for is to specify the allowed requirement switches.
 While there are four different requirement types:  ALTERNATIVE, REQUIRED, CONDITIONAL, DISABLED, AuthenticatorFactory implementations can limit which
 requirement options are shown in the Admin Console when defining a flow. CONDITIONAL should only always be used for subflows, and unless there's a good
-reason for doing otherwise, the requirement on a authenticator should be REQUIRED, ALTERNATIVE and DISABLED:
+reason for doing otherwise, the requirement on an authenticator should be REQUIRED, ALTERNATIVE and DISABLED:
 
 [source,java]
 ----
@@ -792,7 +792,7 @@ Let's take a bigger look at secret-question.ftl  Here's a small code snippet:
         </form>
 ----
 
-Any piece of text enclosed in `${}` corresponds to an attribute or template funtion.
+Any piece of text enclosed in `${}` corresponds to an attribute or template function.
 If you see the form's action, you see it points to `${url.loginAction}`.
 This value is automatically generated when you invoke the AuthenticationFlowContext.form() method.
 You can also obtain this value by calling the AuthenticationFlowContext.getActionURL() method in Java code.
@@ -940,7 +940,7 @@ Your new required action should now be displayed and enabled in the required act
 === Modifying or extending the registration form
 
 It is entirely possible for you to implement your own flow with a set of Authenticators to totally change how registration is done in {project_name}.
-But what you'll usually want to do is just add a little bit of validation to the out of the box registration page.
+But what you'll usually want to do is just add a bit of validation to the out-of-the-box registration page.
 An additional SPI was created to be able to do this.
 It basically allows you to add validation of form elements on the page as well as to initialize UserModel attributes and data after the user has been registered.
 We'll look at both the implementation of the user profile registration processing as well as the registration Google Recaptcha plugin.
@@ -1153,7 +1153,7 @@ One thing to note if you are extending the reset credentials flow.
 The first "authenticator" is just a page to obtain the username or email.
 If the username or email exists, then the AuthenticationFlowContext.getUser() will return the located user.
 Otherwise this will be null.
-This form *WILL NOT* re-ask the user to enter in an email or username if the previous email or username did not exist.
+This form *WILL NOT* re-ask the user to enter an email or username if the previous email or username did not exist.
 You need to prevent attackers from being able to guess valid users.
 So, if AuthenticationFlowContext.getUser() returns null, you should proceed with the flow to make it look like a valid user was selected.
 I suggest that if you want to add secret questions to this flow, you should ask these questions after the email is sent.

server_development/topics/events.adoc

@@ -1,7 +1,7 @@
 [[_events]]
 == Event Listener SPI
 
-Writing a Event Listener Provider starts by implementing the `EventListenerProvider` and `EventListenerProviderFactory` interfaces. Please see the Javadoc
+Writing an Event Listener Provider starts by implementing the `EventListenerProvider` and `EventListenerProviderFactory` interfaces. Please see the Javadoc
 and examples for complete details on how to do this.
 
 For details on how to package and deploy a custom provider refer to the <<_providers,Service Provider Interfaces>> chapter.

server_development/topics/locale-selector.adoc

@@ -9,7 +9,7 @@ This behavior can be changed through the `LocaleSelectorSPI` by implementing the
 
 The `LocaleSelectorProvider` interface has a single method, `resolveLocale`, which must return a locale given a `RealmModel` and a nullable `UserModel`. The actual request is available from the `KeycloakSession#getContext` method.
 
-Custom implementations can extend the `DefaultLocaleSelectorProvider` in order to reuse parts of the default behavior. For example to ignore the `Accept-Language` request header, a custom implementation could extend the default provider, override it's `getAcceptLanguageHeaderLocale`, and return a null value. As a result the locale selection will fall back on the realms's default language.
+Custom implementations can extend the `DefaultLocaleSelectorProvider` in order to reuse parts of the default behavior. For example to ignore the `Accept-Language` request header, a custom implementation could extend the default provider, override it's `getAcceptLanguageHeaderLocale`, and return a null value. As a result the locale selection will fall back on the realm's default language.
 
 [role="_additional-resources"]
 === Additional resources

server_development/topics/providers.adoc

@@ -123,7 +123,7 @@ public class MyThemeSelectorProvider implements ThemeSelectorProvider {
 ==== Show info from your SPI implementation in the Admin Console
 
 Sometimes it is useful to show additional info about your Provider to a {project_name} administrator. You can show provider build time information (for example, version of
-custom provider currently installed), current configuration of the provider (eg. url of remote system your provider talks to) or some operational info
+custom provider currently installed), current configuration of the provider (e.g. url of remote system your provider talks to) or some operational info
 (average time of response from remote system your provider talks to). {project_name} Admin Console provides Server Info page to show this kind of information.
 
 To show info from your provider it is enough to implement `org.keycloak.provider.ServerInfoAwareProviderFactory` interface in your `ProviderFactory`.

server_development/topics/saml-role-mappings-spi.adoc

@@ -1,7 +1,7 @@
 [[_saml_role_mappings_spi]]
 == SAML role mappings SPI
 
-{project_name} defines a SPI for mapping SAML roles into roles that exist in the SP environment. The roles returned by
+{project_name} defines an SPI for mapping SAML roles into roles that exist in the SP environment. The roles returned by
 a third-party IDP might not always correspond to the roles that were defined for the SP application so there is a need for a
 mechanism that allows mapping the SAML roles into different roles. It is used by the SAML adapter after it extracts the roles
 from the SAML assertion to set up the container's security context.

server_development/topics/user-storage/simple-example.adoc

@@ -88,7 +88,7 @@ The `createAdapter()` method uses the helper class `org.keycloak.storage.adapter
 
 Every get method of `AbstractUserAdapter` either returns null or empty collections. However, methods that return role and group mappings will return the default roles and groups configured for the realm for every user.  Every set method of `AbstractUserAdapter` will throw a `org.keycloak.storage.ReadOnlyException`. So if you attempt to modify the user in the Admin Console, you will get an error.
 
-The `getUserById()` method parses the `id` parameter using the `org.keycloak.storage.StorageId` helper class. The `StorageId.getExternalId()` method is invoked to obtain the username embeded in the `id` parameter. The method then delegates to `getUserByUsername()`.
+The `getUserById()` method parses the `id` parameter using the `org.keycloak.storage.StorageId` helper class. The `StorageId.getExternalId()` method is invoked to obtain the username embedded in the `id` parameter. The method then delegates to `getUserByUsername()`.
 
 Emails are not stored, so the `getUserByEmail()` method returns null.
 

server_development/topics/user-storage/stream-interfaces.adoc

@@ -24,13 +24,13 @@ ifeval::[{project_community}==true]
 | `org.keycloak.models` | `GroupModel`, `RoleMapperModel`, `UserCredentialManager`, `UserModel`, `UserProvider`
 | `org.keycloak.models.cache` | `CachedUserModel`, `UserCache`
 | `org.keycloak.storage.federated` | All interfaces
-| `org.kecyloak.storage.user` | `UserQueryProvider`(*)
+| `org.keycloak.storage.user` | `UserQueryProvider`(*)
 endif::[]
 ifeval::[{project_product}==true]
 | `org.keycloak.credential` | `CredentialInputUpdater`(*)
 | `org.keycloak.models` | `GroupModel`, `RoleMapperModel`, `UserModel`
 | `org.keycloak.storage.federated` | All interfaces
-| `org.kecyloak.storage.user` | `UserQueryProvider`(*)
+| `org.keycloak.storage.user` | `UserQueryProvider`(*)
 endif::[]
 |===
 (*) indicates the interface is a _<<_provider_capability_interfaces,capability interface>>_