This is an automated email from the ASF dual-hosted git repository.
danhaywood pushed a commit to branch ISIS-3189
in repository https://gitbox.apache.org/repos/asf/isis.git
commit 40794863925a95a06a395a20afaec2cecc03ab60
Author: Dan Haywood <d...@haywood-associates.co.uk>
AuthorDate: Mon Aug 29 10:30:56 2022 +0100
ISIS-3187: improves docs, is all.
(cherry picked from commit f93112874032a871f51307383b55dab6e4c7d740)
---
.../secman/pages/setting-up-with-shiro.adoc | 2 +-
.../adoc/modules/secman/pages/setting-up.adoc | 28 +++++++++++-----------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git
a/extensions/security/secman/adoc/modules/secman/pages/setting-up-with-shiro.adoc
b/extensions/security/secman/adoc/modules/secman/pages/setting-up-with-shiro.adoc
index 5f67424cbf..19cd843aea 100644
---
a/extensions/security/secman/adoc/modules/secman/pages/setting-up-with-shiro.adoc
+++
b/extensions/security/secman/adoc/modules/secman/pages/setting-up-with-shiro.adoc
@@ -33,7 +33,7 @@ These are called "local" users, as per the
xref:refguide:extensions:index/secman
== Delegate Authentication
-Local authentication - as described in the previous section - does not
actually accomplish much; although Shiro's `Authenticator` implementation is in
use, since the Shiro Realm just queries the SecMan database, there is no real
difference from simply using SecMan's own `Authenticator` impplementation.
+Local authentication - as described in the previous section - does not
actually accomplish much; although Shiro's `Authenticator` implementation is in
use, since the Shiro Realm just queries the SecMan database, there is no real
difference from simply using SecMan's own `Authenticator` implementation.
Where things become more interesting and useful is that Secman's
xref:refguide:extensions:index/secman/delegated/shiro/realm/IsisModuleExtSecmanShiroRealm.adoc[Realm
implementation] also allows an alternative "delegate" realm (eg LDAP) to be
queried.
In such cases Shiro can obtain authentication of "delegated" users is
performed by the delegate realm rather than locally.
diff --git
a/extensions/security/secman/adoc/modules/secman/pages/setting-up.adoc
b/extensions/security/secman/adoc/modules/secman/pages/setting-up.adoc
index 9a5125690e..bb1bdfeb7b 100644
--- a/extensions/security/secman/adoc/modules/secman/pages/setting-up.adoc
+++ b/extensions/security/secman/adoc/modules/secman/pages/setting-up.adoc
@@ -51,7 +51,7 @@ In the webapp module of your application, add the following
dependency:
</dependencies>
----
<.> specify either `isis-extensions-secman-persistence-jpa` or
`isis-extensions-secman-persistence-jdo`, as required
-<.> provides an implementation of `PasswordEncryptionService`
+<.> provides an implementation of `PasswordEncoder`, so that passwords are
only persisted in encrypted form.
[[_update-appmanifest]]
@@ -113,18 +113,18 @@ isis:
secman:
seed:
admin:
- user-name: "secman-admin" <.>
- password: "pass" <1>
- role-name: "isis-ext-secman-admin" <.>
+ user-name: "secman-admin" #<.>
+ password: "pass" #<1>
+ role-name: "isis-ext-secman-admin" #<.>
namespace-permissions:
- sticky: ... <.>
- additional: ... <.>
+ sticky: ... #<.>
+ additional: ... #<.>
regular-user:
- role-name: "isis-ext-secman-user" <.>
- permissions-evaluation-policy: ALLOW_BEATS_VETO <.>
- user-menu-me-action-policy: HIDE <.>
+ role-name: "isis-ext-secman-user" #<.>
+ permissions-evaluation-policy: allow_beats_veto #<.>
+ user-menu-me-action-policy: hide #<.>
user-registration:
- initial-role-names: ... <.>
+ initial-role-names: ... #<.>
----
@@ -293,9 +293,9 @@ When developing the app you will probably be using the H2
in-memory database, an
Even when running in production with a persistent database, running a default
set of fixture scripts may be worthwihle.
One option to setup these users/roles would be to use the
xref:refguide:config:sections/isis.testing.adoc#isis.testing.fixtures.initial-script[isis.testing.fixtures.initial-script]
configuration property.
-However the purpose of that config property is meant to be to specify a demo
scenario for demoing/prototyping, so that's probably not the smartest approach.
+However the purpose of that config property is meant to be to setup an
application-specific scenario for demoing/prototyping, so that's probably not
the smartest approach.
-Better is to write a little domain service to do the seeding of security data
for you.
+A better approach is to write a little domain service to do the seeding of
security data for you.
The service below will set up the default roles and permissions for the
framework's own modules:
[source,java]
@@ -308,10 +308,11 @@ public class SeedSecurityService {
private final FixtureScripts fixtureScripts;
private final TransactionService transactionService;
+ private final IsisSystemEnvironment isisSystemEnvironment;
@EventListener(MetamodelEvent.class)
public void onMetamodelEvent(final MetamodelEvent event) {
- if (event.isPostMetamodel()) {
+ if (event.isPostMetamodel() && isisSystemEnvironment.isPrototyping()) {
runScripts();
transactionService.flushTransaction();
}
@@ -319,7 +320,6 @@ public class SeedSecurityService {
private void runScripts() {
fixtureScripts.run(new CustomRolesAndUsers());
- }
}
----
