April 2017 - jboss-jira - Jboss List Archives

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-130?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-130: --------------------------------- Fix Version/s: 2.1.0.Alpha2 (was: 2.1.0.Alpha1) > JDK9 Support > ------------ > > Key: LOGMGR-130 > URL: https://issues.jboss.org/browse/LOGMGR-130 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: David Lloyd > Fix For: 2.1.0.Alpha2 > > > A few enhancements become possible, desirable, and/or necessary when moving to JDK 9. This is an umbrella parent issue to cover them all. > Note that some of these features may require multi-version JAR building, which Maven cannot yet do. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-131) Add format characters for module name, module version

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-131?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-131: --------------------------------- Fix Version/s: 2.1.0.Alpha2 (was: 2.1.0.Alpha1) > Add format characters for module name, module version > ----------------------------------------------------- > > Key: LOGMGR-131 > URL: https://issues.jboss.org/browse/LOGMGR-131 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: David Lloyd > Fix For: 2.1.0.Alpha2 > > > In JDK9, StackTraceElements contain moduleName and moduleVersion fields. This information is useful for debugging purposes, thus format characters should be allocated towards these values. Ideally it'll be something non-conflicting with respect to log4j and other common ancestor/related frameworks, but that is less important than the basic support. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-133) Use StackWalker to get extended log record information

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-133?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-133: --------------------------------- Fix Version/s: 2.1.0.Alpha2 (was: 2.1.0.Alpha1) > Use StackWalker to get extended log record information > ------------------------------------------------------ > > Key: LOGMGR-133 > URL: https://issues.jboss.org/browse/LOGMGR-133 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: David Lloyd > Fix For: 2.1.0.Alpha2 > > > Under Java 9, you can use a StackWalker to efficiently traverse the stack and return information about callers. Using this mechanism should be substantially better-performing than snapshotting the stack to acquire the calling class information for the extended log record class. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-134) Add module name, module version fields to ExtLogRecord

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-134?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-134: --------------------------------- Fix Version/s: 2.1.0.Alpha2 (was: 2.1.0.Alpha1) > Add module name, module version fields to ExtLogRecord > ------------------------------------------------------ > > Key: LOGMGR-134 > URL: https://issues.jboss.org/browse/LOGMGR-134 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: David Lloyd > Fix For: 2.1.0.Alpha2 > > > It will be necessary for ExtLogRecord to carry additional fields for Java 9 module name and module version. The serialization impact should be analyzed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6384) org.jboss.as.test.integration.web.injection.ServletInjectionTestCase fails if @Ignore is removed

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6384?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-6384: ------------------------------------ Assignee: Stuart Douglas (was: Eduardo Martins) > org.jboss.as.test.integration.web.injection.ServletInjectionTestCase fails if @Ignore is removed > ------------------------------------------------------------------------------------------------ > > Key: WFLY-6384 > URL: https://issues.jboss.org/browse/WFLY-6384 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Eduardo Martins > Assignee: Stuart Douglas > > org.jboss.as.test.integration.web.injection.ServletInjectionTestCase @Ignore should be removed, but if thats done then the test fails. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on ELY-1103: --------------------------------------- I don't want to get too far OT, but just an FYI: this is what changed the local auth behavior: https://github.com/wildfly/wildfly-core/commit/022831491b3b5030b3ff5f9ac8... Before all management clients set local auth clients to "quietAuth=true". The wildfly-config.xml for the CLI has the new version of that prop set to true, so the CLI still does that. The testsuite no longer does but it has a CallbackHandler configured that passes "" to the NameCallback, which works. > Special handling for JBOSS-LOCAL-USER server side authentication > ---------------------------------------------------------------- > > Key: ELY-1103 > URL: https://issues.jboss.org/browse/ELY-1103 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Server, SASL > Reporter: David Lloyd > Fix For: 1.1.0.Beta39 > > > If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity. > With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem. > While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity. > If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested. > Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-136) java.util.logging.LogManager removed deprecated property change listeners

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-136?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-136: --------------------------------- Fix Version/s: (was: 2.1.0.Alpha1) > java.util.logging.LogManager removed deprecated property change listeners > ------------------------------------------------------------------------- > > Key: LOGMGR-136 > URL: https://issues.jboss.org/browse/LOGMGR-136 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: James Perkins > > Both the {{addPropertyChangeListener(PropertyChangeListener}} and {{removePropertyChangeListener(PropertyChangeListener}} were deprecated in Java 8 and removed in Java 9. There are two new replacement methods {{addConfigurationListener(Runnable)}} and {{removeConfigurationListener(Runnable)}} that have been added as replacements. > For the JBoss Log Manager these could likely be no-ops like the originals were. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8649) HttpSession.invalidate() requires additional permissions if Security Manager is enabled

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-8649: ------------------------------------ Summary: HttpSession.invalidate() requires additional permissions if Security Manager is enabled Key: WFLY-8649 URL: https://issues.jboss.org/browse/WFLY-8649 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Ivo Studensky Assignee: Stuart Douglas If Security Manager is enforced and a Servlet invokes {{request.getSession(false).invalidate()}}, it fails due to insufficient permissions as follows: {noformat} 15:04:55,001 ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /form-auth/Logout: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "io.undertow.servlet.GET_CURRENT_REQUEST")" in code source "(vfs:/content/form-auth.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.form-auth.war" from Service Module Loader") at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) at io.undertow.servlet.handlers.ServletRequestContext.current(ServletRequestContext.java:92) at org.wildfly.extension.undertow.deployment.LogoutSessionListener.sessionDestroyed(LogoutSessionListener.java:66) at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:315) at io.undertow.servlet.core.SessionListenerBridge.doDestroy(SessionListenerBridge.java:98) at io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(SessionListenerBridge.java:78) at io.undertow.server.session.SessionListeners.sessionDestroyed(SessionListeners.java:61) at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:551) at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:529) at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198) at org.jboss.as.test.integration.web.formauth.LogoutServlet.processRequest(LogoutServlet.java:45) at org.jboss.as.test.integration.web.formauth.LogoutServlet.doGet(LogoutServlet.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) {noformat} The {{io.undertow.servlet.spec.HttpSessionImpl.invalidate()}} method requires {{RuntimePermission("io.undertow.servlet.GET_CURRENT_REQUEST")}} and also {{RuntimePermission("io.undertow.servlet.spec.UNWRAP_HTTP_SESSION")}}, see https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org... https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org... >From the stacktrace above, I would opt for adding a privileged block into {{io.undertow.servlet.core.SessionListenerBridge#doDestroy(Session)}} as that's a private method. That's the reason why I filed Undertow issue for this. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8648) HttpSession.invalidate() requires additional permissions if Security Manager is enabled

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8648?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-8648: ------------------------------------ Assignee: Stuart Douglas (was: Ivo Studensky) > HttpSession.invalidate() requires additional permissions if Security Manager is enabled > --------------------------------------------------------------------------------------- > > Key: WFLY-8648 > URL: https://issues.jboss.org/browse/WFLY-8648 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Ivo Studensky > Assignee: Stuart Douglas > > If Security Manager is enforced and a Servlet invokes {{request.getSession(false).invalidate()}}, it fails due to insufficient permissions as follows: > {noformat} > 15:04:55,001 ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /form-auth/Logout: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "io.undertow.servlet.GET_CURRENT_REQUEST")" in code source "(vfs:/content/form-auth.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.form-auth.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at io.undertow.servlet.handlers.ServletRequestContext.current(ServletRequestContext.java:92) > at org.wildfly.extension.undertow.deployment.LogoutSessionListener.sessionDestroyed(LogoutSessionListener.java:66) > at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:315) > at io.undertow.servlet.core.SessionListenerBridge.doDestroy(SessionListenerBridge.java:98) > at io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(SessionListenerBridge.java:78) > at io.undertow.server.session.SessionListeners.sessionDestroyed(SessionListeners.java:61) > at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:551) > at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:529) > at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198) > at org.jboss.as.test.integration.web.formauth.LogoutServlet.processRequest(LogoutServlet.java:45) > at org.jboss.as.test.integration.web.formauth.LogoutServlet.doGet(LogoutServlet.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > {noformat} > The {{io.undertow.servlet.spec.HttpSessionImpl.invalidate()}} method requires {{RuntimePermission("io.undertow.servlet.GET_CURRENT_REQUEST")}} and also {{RuntimePermission("io.undertow.servlet.spec.UNWRAP_HTTP_SESSION")}}, see > https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org... > https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org... > From the stacktrace above, I would opt for adding a privileged block into {{io.undertow.servlet.core.SessionListenerBridge#doDestroy(Session)}} as that's a private method. That's the reason why I filed Undertow issue for this. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8648) HttpSession.invalidate() requires additional permissions if Security Manager is enabled

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8648?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved UNDERTOW-1058 to WFLY-8648: ------------------------------------------------ Project: WildFly (was: Undertow) Key: WFLY-8648 (was: UNDERTOW-1058) Component/s: Web (Undertow) (was: Servlet) Affects Version/s: (was: 1.4.12.Final) > HttpSession.invalidate() requires additional permissions if Security Manager is enabled > --------------------------------------------------------------------------------------- > > Key: WFLY-8648 > URL: https://issues.jboss.org/browse/WFLY-8648 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > If Security Manager is enforced and a Servlet invokes {{request.getSession(false).invalidate()}}, it fails due to insufficient permissions as follows: > {noformat} > 15:04:55,001 ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /form-auth/Logout: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "io.undertow.servlet.GET_CURRENT_REQUEST")" in code source "(vfs:/content/form-auth.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.form-auth.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at io.undertow.servlet.handlers.ServletRequestContext.current(ServletRequestContext.java:92) > at org.wildfly.extension.undertow.deployment.LogoutSessionListener.sessionDestroyed(LogoutSessionListener.java:66) > at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:315) > at io.undertow.servlet.core.SessionListenerBridge.doDestroy(SessionListenerBridge.java:98) > at io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(SessionListenerBridge.java:78) > at io.undertow.server.session.SessionListeners.sessionDestroyed(SessionListeners.java:61) > at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:551) > at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:529) > at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198) > at org.jboss.as.test.integration.web.formauth.LogoutServlet.processRequest(LogoutServlet.java:45) > at org.jboss.as.test.integration.web.formauth.LogoutServlet.doGet(LogoutServlet.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > {noformat} > The {{io.undertow.servlet.spec.HttpSessionImpl.invalidate()}} method requires {{RuntimePermission("io.undertow.servlet.GET_CURRENT_REQUEST")}} and also {{RuntimePermission("io.undertow.servlet.spec.UNWRAP_HTTP_SESSION")}}, see > https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org... > https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org... > From the stacktrace above, I would opt for adding a privileged block into {{io.undertow.servlet.core.SessionListenerBridge#doDestroy(Session)}} as that's a private method. That's the reason why I filed Undertow issue for this. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2017