April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8628) SwitchIdentityTestCase cannot authenticate

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8628?page=com.atlassian.jira.plugin.... ] Farah Juma updated WFLY-8628: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9964 > SwitchIdentityTestCase cannot authenticate > ------------------------------------------ > > Key: WFLY-8628 > URL: https://issues.jboss.org/browse/WFLY-8628 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: David Lloyd > Assignee: Farah Juma > Fix For: 11.0.0.Beta1 > > > The two SwitchIdentityTestCase classes both attempt a DIGEST-MD5 authentication. For some reason the authentication is rejected. A debug session shows the user name, password, host name, and protocol all seem to match between client and server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if a JMS message is sent from an MDB

by Scott Van Wart (JIRA)

[ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.... ] Scott Van Wart commented on WFLY-8217: -------------------------------------- I'll try a couple of other things in light of your comments. I'm no CDI expert either. I think we need a support group. I haven't used @TransactionScoped but it sounds suspicious as WELD gives the following warning: {noformat} WELD-001703: Unable to determine the @Intercepted Bean<?> for [UnbackedAnnotatedField] @Inject @Intercepted private com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.interceptedBean {noformat} That's always bothered me but I can't see any immediate ill effects from it. It happens on each and every MDB that has some kind of transaction demarcation (unless it's NOT_SUPPORTED--either through EJB3 annotations or JTA annotations). I wonder if an MDB is defined outside the scope of CDI and I shouldn't be using JTA annotations at all. > ActiveMQ leaks connections if a JMS message is sent from an MDB > --------------------------------------------------------------- > > Key: WFLY-8217 > URL: https://issues.jboss.org/browse/WFLY-8217 > Project: WildFly > Issue Type: Bug > Components: JMS, Transactions > Affects Versions: 10.1.0.Final > Environment: Running on Windows 10. Java(TM) SE Runtime Environment (build 1.8.0_92-b14) > Reporter: Scott Van Wart > Assignee: Jeff Mesnil > Priority: Minor > Attachments: leak.zip, leak.zip, log.txt, log.txt, server.log > > > If an MDB causes a JMS message to be sent during the call to onMessage(), ActiveMQ won't close its connection. I'm using JMS2 through an @Inject'ed JMSContext. My sample project is an EAR with an EJB JAR (containing a service and an MDB) and a JAX-RS endpoint (entry point for the test). > 1) Build the EAR > 2) Run wildfly with the standalone-full.xml configuration: > {{standalone.bat --server-config=standalone-full.xml}} > 3) Enable debug and error reporting for leaked connections with ActiveMQ/CCM: > {{jboss-cli.bat -c}} > {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=debug,value=true)}} > {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=error,value=true)}} > 4) Deploy the EAR. > 5) Access http://localhost:8080/leak-web/rest/test?message=Hi > The REST endpoint will send a message to the test topic (Defined in leak-ejb/src/main/java/test/mdb/TestTopic.java). TestTopicListener (in the same package as TestTopic) will receive the message and send a second message to the topic. Upon returning from TestTopicListener.onMessage(), the message is sent, but this shows up in the logs > (see attached log.txt) > I have no idea why JIRA attached each file twice. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBJCA-1348) Pool duplication when kerberos subject changes (certificate expires and is renewed)

by Stephen Fikes (JIRA)

Stephen Fikes created JBJCA-1348: ------------------------------------ Summary: Pool duplication when kerberos subject changes (certificate expires and is renewed) Key: JBJCA-1348 URL: https://issues.jboss.org/browse/JBJCA-1348 Project: IronJacamar Issue Type: Bug Affects Versions: 1.0.37.Final Reporter: Stephen Fikes Attachments: testcase.zip Using a Kerberos security domain (org.jboss.security.negotiation.KerberosLoginModule) in JBoss EAP 6. When the Kerberos certificate times out and is renewed, the subject used to find the pool no longer matches and a new pool is created for the same user (based on the new credentials). The multiplication of pools makes it possible to exceed the max-pool-size with a single user (ActiveCount, etc. can exceed max-pool-size). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1536) Augment KieAssembler with a kjar context

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1536?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1536: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Augment KieAssembler with a kjar context > ---------------------------------------- > > Key: DROOLS-1536 > URL: https://issues.jboss.org/browse/DROOLS-1536 > Project: Drools > Issue Type: Enhancement > Reporter: Matteo Mortari > Assignee: Mario Fusco > > Currently KieAssembler are created per-runtime and cached globally, a sort of a singleton. > There is a need to have a "kjar context" so that KieAssembler might be able to cache some resources as needed on a per-kjar basis. > Currently this is not possible because indeed KieAssemblers are created at runtime singleton-like level, and unaware of the kjar context. > (a KBuilder is passed, but this would offer only a creation-time context, and a cache based on this could not realize when the related kjar context is no longer needed.) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1536) Augment KieAssembler with a kjar context

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1536: -------------------------------------- Summary: Augment KieAssembler with a kjar context Key: DROOLS-1536 URL: https://issues.jboss.org/browse/DROOLS-1536 Project: Drools Issue Type: Enhancement Reporter: Matteo Mortari Assignee: Edson Tirelli Currently KieAssembler are created per-runtime and cached globally, a sort of a singleton. There is a need to have a "kjar context" so that KieAssembler might be able to cache some resources as needed on a per-kjar basis. Currently this is not possible because indeed KieAssemblers are created at runtime singleton-like level, and unaware of the kjar context. (a KBuilder is passed, but this would offer only a creation-time context, and a cache based on this could not realize when the related kjar context is no longer needed.) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2718) Management HTTP API using security-realm for CLIENT_CERT authentication results in prompt for password instead of directly authenticating

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2718?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2718: ------------------------------------- Fix Version/s: 3.0.0.Beta17 > Management HTTP API using security-realm for CLIENT_CERT authentication results in prompt for password instead of directly authenticating > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2718 > URL: https://issues.jboss.org/browse/WFCORE-2718 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 3.0.0.Beta16 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Labels: management-security, regression, security-realm, ssl > Fix For: 3.0.0.Beta17 > > > Having defined CLIENT_CERT auth on HTTP management API with legacy security-realm causes that after requesting client cert, there is also required password. > This is regression in comparison to EAP 7.0 and EAP 7.1.0.DR7, as such marking as blocker. > For details how to reproduce see steps to reproduce -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2718) Management HTTP API using security-realm for CLIENT_CERT authentication results in prompt for password instead of directly authenticating

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2718?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved JBEAP-10509 to WFCORE-2718: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2718 (was: JBEAP-10509) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management Security (was: Domain Management) (was: Security) Affects Version/s: 3.0.0.Beta16 (was: 7.1.0.DR8) (was: 7.1.0.DR16) Affects Testing: (was: Regression) > Management HTTP API using security-realm for CLIENT_CERT authentication results in prompt for password instead of directly authenticating > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2718 > URL: https://issues.jboss.org/browse/WFCORE-2718 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 3.0.0.Beta16 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Labels: management-security, regression, security-realm, ssl > Fix For: 3.0.0.Beta17 > > > Having defined CLIENT_CERT auth on HTTP management API with legacy security-realm causes that after requesting client cert, there is also required password. > This is regression in comparison to EAP 7.0 and EAP 7.1.0.DR7, as such marking as blocker. > For details how to reproduce see steps to reproduce -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2646) Elytron, management interface, legacy authentication is "checked" even if Elytron authentication is configured

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2646?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2646: ------------------------------------- Fix Version/s: 3.0.0.Beta17 > Elytron, management interface, legacy authentication is "checked" even if Elytron authentication is configured > --------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2646 > URL: https://issues.jboss.org/browse/WFCORE-2646 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta17 > > > Regression against DR15. > Authentication by legacy security realm is taken in account even if just Elytron authentication should be used. I don't say legacy authentication is used in priority before Elytron (that works as expected). Just that legacy authentication is somehow "initialized". In this case check "There are no user in mngmt-user.properties file" is performed > Reproducer: > * Configure Elytron authentication for management interface > {code} > /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password( clear={password="password123"}) > /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles) > /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=default-permission-mapper) > /subsystem=elytron/http-authentication-factory=example-fs-http-auth:add(http-server-mechanism-factory=global,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=exampleApplicationDomain}]}]) > /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-fs-http-auth) > {code} > * impossible to acces management interface > {code} > curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se... > { > "outcome" : "failed", > "failure-description" : "WFLYDMHTTP0006: The security realm is not ready to process requests, see http://localhost.localdomain:9990/error", > "rolled-back" : "true" > } > {code} > Access is granted once > * security realm is undefined from management interface > {code} > /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm) > {code} > * Or user is added into ManagementRealm > {code} > ./add-user.sh -u admin -p admin -r ManagementRealm > {code} > {code} > curl --user user1:password123 http://localhost.localdomain:9990/management?operation=attribute\&name=se... > "running" > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2678) LDAP credential is revealed when error occurs at startup

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2678?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration updated WFCORE-2678: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1443122 Bugzilla Update: Perform > LDAP credential is revealed when error occurs at startup > -------------------------------------------------------- > > Key: WFCORE-2678 > URL: https://issues.jboss.org/browse/WFCORE-2678 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: - EAP 6.4.13 > Reporter: Hisanobu Okuda > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta16 > > > When an error occurs at startup, LDAP credential is shown in the log file. It should not appear. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2717) try-catch block doesn't work if catch block doesn't contains anything

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2717?page=com.atlassian.jira.plugi... ] Ingo Weiss moved JBEAP-10507 to WFCORE-2717: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2717 (was: JBEAP-10507) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Affects Version/s: (was: 7.1.0.DR16) > try-catch block doesn't work if catch block doesn't contains anything > --------------------------------------------------------------------- > > Key: WFCORE-2717 > URL: https://issues.jboss.org/browse/WFCORE-2717 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Ingo Weiss > Assignee: Ingo Weiss > > Try-catch block doesn't work if catch block doesn't contains anything > *Steps to reproduce:* > {noformat} > rm -f a.cli > cat << EOF > a.cli > try > echo try-block > /system-property=nonsence:read-resource() > catch > # echo catch-block > end-try > echo after-block > EOF > ./jboss-cli.sh -c --file=a.cli > {noformat} > *Actual results:* > {noformat} > [mkopecky@dhcp-10-40-4-227 bin]$ ./jboss-cli.sh -c --file=a.cli > try-block > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[(\"system-property\" => \"nonsence\")]' not found", > "rolled-back" => true > } > [mkopecky@dhcp-10-40-4-227 bin]$ > {noformat} > *Expected results:* > {noformat} > [mkopecky@dhcp-10-40-4-227 bin]$ ./jboss-cli.sh -c --file=a.cli > try-block > after-block > [mkopecky@dhcp-10-40-4-227 bin]$ > {noformat} > *Additional info:* > This issue is not regression -- 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