July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6809) Web authentication not treating "**" role constraint as expected

by arjan tijms (JIRA)

[ https://issues.jboss.org/browse/WFLY-6809?page=com.atlassian.jira.plugin.... ] arjan tijms commented on WFLY-6809: ----------------------------------- The Servlet spec lead essentially has clarified this some time ago on his personal blog. See this archived version: https://web.archive.org/web/20150912103140/https://weblogs.java.net/blog/... (or the current automatically migrated one, which however formats horribly: https://community.oracle.com/blogs/swchan2/2013/04/19/role-servlet-31-sec...) I also had a chat with the JACC spec lead about this some time ago. He clarified that in a full Java EE product, the Servlet container *must* follow the JACC spec. So in this case 3.1.3.2 of the JACC spec applies, where a {{WebResourcePermission}} must indeed be added and enforced for the pre-dispatch (authorization) outcome. _(actually according to the JACC spec lead the Servlet container in a full Java EE server must use the default JACC provider at run time for the pre-dispatch outcome as well as the programmatic role checks. Although in JBoss/WildFly the default JACC provider is available and initialised, it's not actually used by the Servlet container)_ > Web authentication not treating "**" role constraint as expected > ---------------------------------------------------------------- > > Key: WFLY-6809 > URL: https://issues.jboss.org/browse/WFLY-6809 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Guillermo González de Agüero > Assignee: Stuart Douglas > Attachments: rolestest.war > > > Servlet spec 3.1 states at point 13.3: > ??If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.?? > But Undertow treats the special role "**" as any other. With the following web.xml authorization succeeds, but authorization fails (403): > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" > version="3.1"> > <security-constraint> > <web-resource-collection> > <url-pattern>/*</url-pattern> > </web-resource-collection> > <auth-constraint> > <role-name>**</role-name> > </auth-constraint> > </security-constraint> > <login-config> > <auth-method>BASIC</auth-method> > </login-config> > </web-app> > {code} > With the following, and authenticating a user that has a role "**", the requested page is shown: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" > version="3.1"> > <security-constraint> > <web-resource-collection> > <url-pattern>/*</url-pattern> > </web-resource-collection> > <auth-constraint> > <role-name>**</role-name> > </auth-constraint> > </security-constraint> > <login-config> > <auth-method>BASIC</auth-method> > </login-config> > <security-role> > <role-name>**</role-name> > </security-role> > </web-app> > {code} > Reproducer war is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6838) RPCs to non-existant FORK channel are dropped

by Dennis Reed (JIRA)

Dennis Reed created WFLY-6838: --------------------------------- Summary: RPCs to non-existant FORK channel are dropped Key: WFLY-6838 URL: https://issues.jboss.org/browse/WFLY-6838 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.Final Reporter: Dennis Reed Assignee: Dennis Reed RPCs sent to a FORK channel that is not currently running are not responded to correctly, causing the caller to eventually time out. An error response is being sent by org.jboss.as.clustering.jgroups.JChannelFactory, but the request ID is hard-coded to 0 so the reply can not be routed back to the sender and gets dropped. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6837) [GSS](7.0.z) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee

by Robert Bost (JIRA)

Robert Bost created WFLY-6837: --------------------------------- Summary: [GSS](7.0.z) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee Key: WFLY-6837 URL: https://issues.jboss.org/browse/WFLY-6837 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Robert Bost Assignee: Aaron Ogburn Fix For: 10.1.0.Final JASPICSecureResponseHandler.handleRequest can throw a NPE for a redirect from a CONFIDENTIAL transport guarantee: {code} java.lang.NullPointerException at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:35) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {code} This occurs because io.undertow.security.handlers.AbstractConfidentialityHandler generates the redirect before any JASPICContext is placed on the request, so JASPICSecureResponseHandler sees the null. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2044) RequestCorrelator causes frequent boxing and autoboxing by using a Map<Long, Request>

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2044?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2044 at 7/15/16 12:27 PM: ---------------------------------------------------------- How do you see boxing/unboxing in JFR? And what was the percentage you were seeing? I've looked into this before in JGRP-1982 and decided against it. I've changed this in my private branch to use Trove's {{TLongObjectHashMap}}, but this * introduces a dependency which I don't want and * {{TLongObjectHashMap}} is not concurrent (as {{ConcurrentHashMap}}, and therefore every access needs to be synchronized, slowing things down was (Author: belaban): How do you see boxing/unboxing in JFR? > RequestCorrelator causes frequent boxing and autoboxing by using a Map<Long,Request> > ------------------------------------------------------------------------------------ > > Key: JGRP-2044 > URL: https://issues.jboss.org/browse/JGRP-2044 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > The JFR profiler is highlighting a significant amount of boxing and autoboxing, as the request is is treated as a {{long}} but this is used as an key for the {{Map<Long,Request>}}. > We could try to either consistently use {{Long}} rather than {{long}}, or even better figure out an optimal data structure to replace the implementation of the Map to not require boxing of the keys. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2044) RequestCorrelator causes frequent boxing and autoboxing by using a Map<Long, Request>

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2044?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2044: -------------------------------- How do you see boxing/unboxing in JFR? > RequestCorrelator causes frequent boxing and autoboxing by using a Map<Long,Request> > ------------------------------------------------------------------------------------ > > Key: JGRP-2044 > URL: https://issues.jboss.org/browse/JGRP-2044 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > The JFR profiler is highlighting a significant amount of boxing and autoboxing, as the request is is treated as a {{long}} but this is used as an key for the {{Map<Long,Request>}}. > We could try to either consistently use {{Long}} rather than {{long}}, or even better figure out an optimal data structure to replace the implementation of the Map to not require boxing of the keys. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6787) WebSockets compression should be allowed by default

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-6787?page=com.atlassian.jira.plugin.... ] Ingo Weiss updated WFLY-6787: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9001, https://github.com/wildfly/wildfly/pull/9043 (was: https://github.com/wildfly/wildfly/pull/9001) > WebSockets compression should be allowed by default > --------------------------------------------------- > > Key: WFLY-6787 > URL: https://issues.jboss.org/browse/WFLY-6787 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Ingo Weiss > Assignee: Ingo Weiss > > In EAP 6.4 there was allowed WebSockets compression by default if requested by client. In EAP 7 it is not. I believe it should be also allowed by default in EAP 7. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2044) RequestCorrelator causes frequent boxing and autoboxing by using a Map<Long, Request>

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2044?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2044: --------------------------- Comment: was deleted (was: This is the right link) > RequestCorrelator causes frequent boxing and autoboxing by using a Map<Long,Request> > ------------------------------------------------------------------------------------ > > Key: JGRP-2044 > URL: https://issues.jboss.org/browse/JGRP-2044 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > The JFR profiler is highlighting a significant amount of boxing and autoboxing, as the request is is treated as a {{long}} but this is used as an key for the {{Map<Long,Request>}}. > We could try to either consistently use {{Long}} rather than {{long}}, or even better figure out an optimal data structure to replace the implementation of the Map to not require boxing of the keys. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6835) Vault.sh misleading output

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6835?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-6835: ---------------------------------------- If we go for CLI commands, there should be two examples, one for a standalone server, one for a host controller. Difference is a preceding /host=the_host in the command address. > Vault.sh misleading output > -------------------------- > > Key: WFLY-6835 > URL: https://issues.jboss.org/browse/WFLY-6835 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Minor > > Vault.sh advise to insert vault xml snippet as follows: > {code} > Vault Configuration in AS7 config file: > ******************************************** > ... > </extensions> > <vault> > <vault-option name="KEYSTORE_URL" value="EAP_HOME/vault/vault.keystore"/> > <vault-option name="KEYSTORE_PASSWORD" value="MASK-5dOaAVafCSd"/> > <vault-option name="KEYSTORE_ALIAS" value="vault"/> > <vault-option name="SALT" value="1234abcd"/> > <vault-option name="ITERATION_COUNT" value="120"/> > <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/> > </vault><management> ... > ******************************************** > {code} > 1. User can insert this snippet on wrong place. See forum link for example. Pobably CLI command would be more suitable? > {code} > /core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"),("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"),("KEYSTORE_ALIAS" => "ALIAS"),("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"),("ENC_FILE_DIR" => "ENC_FILE_DIR")]) > {code} > 2. There is still reference to AS7 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2052) Timer: make timer thread pool and timer queue configurable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2052?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2052. ---------------------------- Resolution: Done > Timer: make timer thread pool and timer queue configurable > ---------------------------------------------------------- > > Key: JGRP-2052 > URL: https://issues.jboss.org/browse/JGRP-2052 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > The timer ({{TimeScheduler3}}) currently has the thread pool enabled by default and the pool's queue is always on. Add 2 properties: > # {{timer_thread_pool.enabled}}: enables or disables the timer's thread pool and > # {{timer.queue_enabled}}: enables or disables the thread pool's queue. > The timer has a runner thread which continually removes tasks scheduled for execution (from a {{DelayQueue}}) and dispatches the tasks to the thread pool. If the pool is disabled (#1), then it is the runner thread which executes the task directly. This makes sense for instance, when the timer only has non-blocking tasks. An example for a blocking task is a retransmission, which might block on the send side due to insufficient credits. The timer's thread pool is by default _enabled_, but it can now be disabled to reduce the threads running. > Enabling the thread pool, but disabling the timer's queue means that the pool will allocate threads up to max-threads immediately, rather than queuing the tasks. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ] Petr Široký commented on DROOLS-355: ------------------------------------ * I tried to run the test in this PR https://github.com/droolsjbpm/drools/pull/834 on JDK 9 and that works as expected. * I _think_ it should also work with module-info.java (assuming the jaxb-xjc is modularized -- or present in the unnamed module). But this needs to be tested. * WildFly migrated to {{org.glassfish.jaxb}} groupId (which still contains the same com.sun.* packages), https://github.com/wildfly/wildfly/blob/10.0.0.Final/pom.xml#L1462 * I agree that using com.sun packages is far from ideal, but if it works, it is much less of an issue > Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9 > ------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-355 > URL: https://issues.jboss.org/browse/DROOLS-355 > Project: Drools > Issue Type: Task > Affects Versions: 6.0.0.Final > Reporter: Geoffrey De Smet > Assignee: Petr Široký > Priority: Blocker > > By importing com.sun.tools.xjc, 3 problems arise: > * OSGi and Karaf trip over it. > {code} > [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final) > {code} > * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013. > * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this? > Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now. > Where do we use it? > {code} > Targets > String 'com.sun.tools.xjc' > Found usages (38 usages found) > drools-compiler (7 usages found) > /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found) > pom.xml (1 usage found) > (246: 15) com.sun.tools.xjc.*;resolution:=optional, > org.drools.compiler.builder.impl (1 usage found) > KnowledgeBuilderFactoryServiceImpl.java (1 usage found) > (18: 8) import com.sun.tools.xjc.Options; > org.drools.compiler.runtime.pipeline.impl (5 usages found) > DroolsJaxbHelperProviderImpl.java (5 usages found) > (77: 8) import com.sun.tools.xjc.BadCommandLineException; > (78: 8) import com.sun.tools.xjc.ErrorReceiver; > (79: 8) import com.sun.tools.xjc.ModelLoader; > (80: 8) import com.sun.tools.xjc.Options; > (81: 8) import com.sun.tools.xjc.model.Model; > drools-core (2 usages found) > org.drools.core.builder.conf.impl (2 usages found) > JaxbConfigurationImpl.java (2 usages found) > (28: 8) import com.sun.tools.xjc.Language; > (34: 8) import com.sun.tools.xjc.Options; > kie-internal (6 usages found) > /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found) > pom.xml (1 usage found) > (27: 15) com.sun.tools.xjc;resolution:=optional, > org.kie.internal.builder (3 usages found) > JaxbConfiguration.java (1 usage found) > (23: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactory.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactoryService.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > org.kie.internal.builder.help (2 usages found) > DroolsJaxbHelperProvider.java (1 usage found) > (29: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderHelper.java (1 usage found) > (30: 8) import com.sun.tools.xjc.Options; > knowledge-api (8 usages found) > org.drools.builder (3 usages found) > JaxbConfiguration.java (1 usage found) > (21: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactory.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactoryService.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > org.drools.builder.help (3 usages found) > DroolsJaxbHelperProvider.java (1 usage found) > (29: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderHelper.java (2 usages found) > (32: 8) import com.sun.tools.xjc.Language; > (33: 8) import com.sun.tools.xjc.Options; > org.drools.impl (1 usage found) > KnowledgeBuilderFactoryServiceImpl.java (1 usage found) > (16: 8) import com.sun.tools.xjc.Options; > org.drools.impl.adapters (1 usage found) > JaxbConfigurationAdapter.java (1 usage found) > (3: 8) import com.sun.tools.xjc.Options; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016