[JBoss JIRA] (WFCORE-3780) Provide Elytron alternative to RoleMappingLoginModule
by Derek Horton (JIRA)
Derek Horton created WFCORE-3780:
------------------------------------
Summary: Provide Elytron alternative to RoleMappingLoginModule
Key: WFCORE-3780
URL: https://issues.jboss.org/browse/WFCORE-3780
Project: WildFly Core
Issue Type: Feature Request
Components: Security
Affects Versions: 4.0.0.Final
Reporter: Derek Horton
In picketbox there is RoleMappingLoginModule [1], which takes role as returned from authorization process and maps to different role. I thought something similar should be configurable with some of Elytron role-mappers. But looking into model/code, it is not obvious to me which of them can be used. I know custom role mapper can be still used, but I wonder if we really do not provide this common funcionality out of the box with Elytron.
Another workaround is to use direct roles from realm (e.g. LDAP ) in target (e.g. web.xml). But seems users tend to map IDM Roles to applicaiton roles.
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3778) The EmbeddedManagedProcess should have a start method which accepts a timeout for the server to start
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3778?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3778:
----------------------------------
Issue Type: Feature Request (was: Enhancement)
> The EmbeddedManagedProcess should have a start method which accepts a timeout for the server to start
> -----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3778
> URL: https://issues.jboss.org/browse/WFCORE-3778
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Embedded
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently the {{EmbeddedManagedProcess}}, which both the {{StandaloneServer}} and {{HostController}} extend, only contains a {{start()}} method which immediately returns. There should be a {{start(int timeout)}} which will wait the specified amount of time then throw an exception is the server was not successfully started within that time. A timeout of 0 or less would mean no timeout was specified and the {{start()}} method should just return immediately.
> This could also be a setting on the new {{Configuration}} API so the default {{start()}} method would have a timeout associated with it. A value of 0 should be the default so there are no behavioral changes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10315) Restore legacy (not "graceful") startup mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10315?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-10315:
-----------------------------------------
Can you describe your use case further? The configuration service must be started or it doesn't provide a useful response. So are there other deployments on the same server that are delaying things?
Or, perhaps this is a request for the server to not block incoming requests while waiting for graceful startup, but rather to respond immediately with an error response? If so there is a separate RFE for that: https://github.com/wildfly/wildfly-proposals/pull/34/files
> Restore legacy (not "graceful") startup mode
> --------------------------------------------
>
> Key: WFLY-10315
> URL: https://issues.jboss.org/browse/WFLY-10315
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Vladimir Grabarchuk
> Assignee: Jason Greene
>
> Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components.
> The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether.
> If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months