[
https://issues.jboss.org/browse/WFLY-4880?page=com.atlassian.jira.plugin....
]
Josef Cacek commented on WFLY-4880:
-----------------------------------
What if the permission classes are part of the deployed application(s)?
_We have a similar issue with login modules in security domains. If I recall it correctly,
then there is no need to provide {{module}} attribute. Nevertheless, if more deployments
use the same security domain, then the first login request initializes the custom login
module from the deployment which threw the login request. All other login requests to the
same security domain goes through this initialized login module class (from the first hit
deployment) even if they come from another deployments._
The same as {{maximum-set}} applies to {{minimum-set}}.
And what about the {{/deployment-permissions=default}} on the parent level? Is there a
plan to have several set of deployment-permissions? If not what about to make it shorter
and use following paths?
{{/subsystem=security-manager/deployment-permissions=maximum-set:add(...)}}
{{/subsystem=security-manager/deployment-permissions=minimum-set:add(...)}}
Permission names are not persisted in the domain model
------------------------------------------------------
Key: WFLY-4880
URL:
https://issues.jboss.org/browse/WFLY-4880
Project: WildFly
Issue Type: Bug
Components: Domain Management, Security Manager
Affects Versions: 10.0.0.Alpha4
Reporter: Josef Cacek
Assignee: Kabir Khan
Priority: Blocker
Permission names used in the {{security-manager}} subsystem model are not persisted. It
can simply lead to non-bootable server configuration.
Expected behavior:
The names used for permission model nodes are persisted in the model (e.g. in an
{{alias}} attribute).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)