Merge pull request #99 from jenmalloy/RHSSO-941-take4
fixed additional issues with RHSSO-941
This commit is contained in:
commit
1b46b25226
2 changed files with 3 additions and 3 deletions
|
@ -3,7 +3,7 @@
|
|||
|
||||
Our `PropertyFileUserStorageProvider` example is bit contrived. It is hardcoded to a property file that is embedded in the jar of the provider. Not very useful at all. We might want to make the location of this file configurable per instance of the provider. In other words, we might want to reuse this provider mulitple times in multiple different realms and point to completely different user property files. We'll also want to perform this configuration within the administration console UI.
|
||||
|
||||
The `UserStorageProviderFactory` has additional methods you can implement that deal with provider configuration. You describe the variables you want to configure per provider and the administration console automatically renders a generic input page to gather this configuration. Callback methods also validate the configuration before it is saved, when a provider is created for the first time, and when it is updated. `UserStorageProviderFactory` inherits these methods from the `org.keycloak.component.ComponentFactory` interface.
|
||||
The `UserStorageProviderFactory` has additional methods you can implement that handle provider configuration. You describe the variables you want to configure per provider and the administration console automatically renders a generic input page to gather this configuration. When implemented, callback methods also validate the configuration before it is saved, when a provider is created for the first time, and when it is updated. `UserStorageProviderFactory` inherits these methods from the `org.keycloak.component.ComponentFactory` interface.
|
||||
|
||||
[source,java]
|
||||
----
|
||||
|
|
|
@ -204,7 +204,7 @@ The `getId()` method identifies the factory in the runtime and will also be the
|
|||
}
|
||||
----
|
||||
|
||||
The `UserStorageProviderFactory` interface has an optional `init()` method you can implement. When {{book.project.name}} boots up, one and only one instance of each different provider factory. Also at boot time, the `init()` method will be called on each one of these factory instances. There's also a `postInit()` method you can implement as well. After each factory's `init()` method is invoked, their `postInit()` methods will be called.
|
||||
The `UserStorageProviderFactory` interface has an optional `init()` method you can implement. When {{book.project.name}} boots up, only one instance of each provider factory is created. Also at boot time, the `init()` method is called on each of these factory instances. There's also a `postInit()` method you can implement as well. After each factory's `init()` method is invoked, their `postInit()` methods are called.
|
||||
|
||||
In our `init()` method implementation, we find the property file containing our user declarations from the classpath. We then load the `properties` field with the username and password combinations stored there.
|
||||
|
||||
|
@ -282,4 +282,4 @@ When you go back to the main `User Federation` page, you now see your provider l
|
|||
image:../../{{book.images}}/user-federation-page.png[]
|
||||
{% endif %}
|
||||
|
||||
You will now be able to log in with a user declared in the `users.properties` file. This user will have read-only access, and as such will only be able to view the account page after logging in.
|
||||
You will now be able to log in with a user declared in the `users.properties` file. This user will only be able to view the account page after logging in.
|
||||
|
|
Loading…
Reference in a new issue