February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9928) Replace usage of deprecated ServiceListener with LifecycleListener in singleton deployment logic

by Dmitrii Tikhomirov (JIRA)

[ https://issues.jboss.org/browse/WFLY-9928?page=com.atlassian.jira.plugin.... ] Dmitrii Tikhomirov reassigned WFLY-9928: ---------------------------------------- Assignee: Dmitrii Tikhomirov (was: Paul Ferraro) > Replace usage of deprecated ServiceListener with LifecycleListener in singleton deployment logic > ------------------------------------------------------------------------------------------------ > > Key: WFLY-9928 > URL: https://issues.jboss.org/browse/WFLY-9928 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Dmitrii Tikhomirov > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-46) Build CI pipeline on Openshif.io

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/SWSQE-46?page=com.atlassian.jira.plugin.s... ] Hayk Hovsepyan updated SWSQE-46: -------------------------------- Sprint: SWS QE Sprint 2 > Build CI pipeline on Openshif.io > --------------------------------- > > Key: SWSQE-46 > URL: https://issues.jboss.org/browse/SWSQE-46 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-46) Build CI pipeline on Openshif.io

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-46: ----------------------------------- Summary: Build CI pipeline on Openshif.io Key: SWSQE-46 URL: https://issues.jboss.org/browse/SWSQE-46 Project: Swift Sunshine QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2253: -------------------------------- Actually, I changed this from WARN --> DEBUG because connecting to an unreachable destination is a normal scenario, not a failure, so I don't want to log this as WARN... > FD_SOCK is not working in AWS environment > ----------------------------------------- > > Key: JGRP-2253 > URL: https://issues.jboss.org/browse/JGRP-2253 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.10 > Environment: AWS - EC2 > Reporter: Sibin Karnavar > Assignee: Bela Ban > > We have our failure detection defined like below. > <FD_SOCK external_port="7804" /> > <FD timeout="3000" max_tries="3" /> > <VERIFY_SUSPECT timeout="3000" /> > Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing. > In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK. > We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port. > Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS. > Thanks, > Sibin -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3657) Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3657?page=com.atlassian.jira.plugi... ] Jan Kalina moved WFLY-9442 to WFCORE-3657: ------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-3657 (was: WFLY-9442) Component/s: Security (was: Security) > Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-3657 > URL: https://issues.jboss.org/browse/WFCORE-3657 > Project: WildFly Core > Issue Type: Enhancement > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > One of the scenarios which are expected to work in Elytron is a Security context propagation from a protected EJB to a protected Servlet using HttpUrlConnection (details in RFE EAP7-284). > The scenario doesn't work for me. My configuration: > {noformat} > EJB client -> protected EJB on server-1 -> protected Servlet on server-2 (BASIC authn) > {noformat} > The EJB contains following code: > {code:java} > final Callable<String> callable = () -> { > URLConnection conn = url.openConnection(); > conn.connect(); > try (InputStream is = conn.getInputStream()) { > return IOUtils.toString(is, StandardCharsets.UTF_8); > } > }; > AuthenticationContext.empty().with(MatchRule.ALL, AuthenticationConfiguration.empty() > .useForwardedIdentity(SecurityDomain.getCurrent()) > .setSaslMechanismSelector(SaslMechanismSelector.ALL)) > .runCallable(callable); > {code} > The server-2 returns 401: > {noformat} > java.io.IOException: Server returned HTTP response code: 401 for URL: http://127.0.0.1:8180/seccontext-server2/whoAmI > at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474) > at org.wildfly.test.manual.elytron.seccontext.EntryBean.lambda$readUrl$1(EntryBean.java:69) > {noformat} > There is still a chance, the problem is in the scenario configuration, but the documentation is silent about this topic. > The problem could be in a missing integration of ElytronAuthenticator within the AuthenticationContext. I don't see it used when I debug the scenario. When I register the authenticator manually, I see another problem which will be reported in a separate JIRA. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9442) Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-9442?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-9442: -------------------------------- Assignee: Jan Kalina (was: Pedro Igor) > Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario > ------------------------------------------------------------------------------------------------- > > Key: WFLY-9442 > URL: https://issues.jboss.org/browse/WFLY-9442 > Project: WildFly > Issue Type: Enhancement > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > One of the scenarios which are expected to work in Elytron is a Security context propagation from a protected EJB to a protected Servlet using HttpUrlConnection (details in RFE EAP7-284). > The scenario doesn't work for me. My configuration: > {noformat} > EJB client -> protected EJB on server-1 -> protected Servlet on server-2 (BASIC authn) > {noformat} > The EJB contains following code: > {code:java} > final Callable<String> callable = () -> { > URLConnection conn = url.openConnection(); > conn.connect(); > try (InputStream is = conn.getInputStream()) { > return IOUtils.toString(is, StandardCharsets.UTF_8); > } > }; > AuthenticationContext.empty().with(MatchRule.ALL, AuthenticationConfiguration.empty() > .useForwardedIdentity(SecurityDomain.getCurrent()) > .setSaslMechanismSelector(SaslMechanismSelector.ALL)) > .runCallable(callable); > {code} > The server-2 returns 401: > {noformat} > java.io.IOException: Server returned HTTP response code: 401 for URL: http://127.0.0.1:8180/seccontext-server2/whoAmI > at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474) > at org.wildfly.test.manual.elytron.seccontext.EntryBean.lambda$readUrl$1(EntryBean.java:69) > {noformat} > There is still a chance, the problem is in the scenario configuration, but the documentation is silent about this topic. > The problem could be in a missing integration of ElytronAuthenticator within the AuthenticationContext. I don't see it used when I debug the scenario. When I register the authenticator manually, I see another problem which will be reported in a separate JIRA. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2353) [DMN Editor] Add support for deleting expression type and revert to 'Undefined'

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2353?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2353: -------------------------------- Tester: Jozef Marko > [DMN Editor] Add support for deleting expression type and revert to 'Undefined' > -------------------------------------------------------------------------------- > > Key: DROOLS-2353 > URL: https://issues.jboss.org/browse/DROOLS-2353 > Project: Drools > Issue Type: Sub-task > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > > Various Expression editors allow for nested expressions. > Once a nested expression type has been set it is not possible to change it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS

by Martin Švehla (JIRA)

[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ] Martin Švehla commented on WFLY-9892: ------------------------------------- [~pcraveiro] so what's the suggested solution here? Leave it and add a note to docs/known issues? Yeah PicketLink is deprecated but some users still use it and this will break their migrated apps. But I think we could get away with documenting the change. cc [~bilge] > Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS > -------------------------------------------------------------------------------- > > Key: WFLY-9892 > URL: https://issues.jboss.org/browse/WFLY-9892 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 12.0.0.Beta1 > Reporter: Ondrej Lukas > Assignee: Pedro Igor > Priority: Blocker > Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties > > > When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly. > We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly. > Remoting fails due to following exception: > {code} > java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA" > at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117) > at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295) > at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196) > at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54) > at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55) > at java.security.AccessController.doPrivileged(Native Method) > at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374) > at java.lang.Thread.run(Thread.java:748) > {code} > It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like: > {code} > <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue> > {code} > In WildFly 12 it looks like (there are end of lines): > {code} > <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl > qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI > 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N > K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7 > nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue> > {code} > [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9908) Unused PathAddress variable in BroadcastGroupAdd.performRuntime method

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9908?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9908: --------------------------------- Priority: Trivial (was: Minor) > Unused PathAddress variable in BroadcastGroupAdd.performRuntime method > ---------------------------------------------------------------------- > > Key: WFLY-9908 > URL: https://issues.jboss.org/browse/WFLY-9908 > Project: WildFly > Issue Type: Bug > Components: Clustering, JMS > Affects Versions: 12.0.0.Beta1 > Reporter: Martin Styk > Assignee: Radoslav Husar > Priority: Trivial > > Variable {{final PathAddress address}} in method {{BroadcastGroupAdd.performRuntime}} is declared but never used. > {code} > @Override > protected void performRuntime(OperationContext context, ModelNode operation, ModelNode model) throws OperationFailedException { > ... > else { > final PathAddress address = context.getCurrentAddress(); > final String name = context.getCurrentAddressValue(); > final ServiceTarget target = context.getServiceTarget(); > if (model.hasDefined(JGROUPS_CLUSTER.getName())) { > // nothing to do, in that case, the clustering.jgroups subsystem will have setup the stack > } else if(model.hasDefined(RemoteTransportDefinition.SOCKET_BINDING.getName())) { > final GroupBindingService bindingService = new GroupBindingService(); > target.addService(GroupBindingService.getBroadcastBaseServiceName(serviceName).append(name), bindingService) > .addDependency(SocketBinding.JBOSS_BINDING_NAME.append(model.get(SOCKET_BINDING).asString()), SocketBinding.class, bindingService.getBindingRef()) > .install(); > } > } > } > {code} > https://github.com/wildfly/wildfly/blame/master/messaging-activemq/src/ma... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9854) jgroups-channel cannot use name which is already used by jgroups/stacks

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-9854?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-9854: ----------------------------- [~ccopello] [~bprioux] Please see the above comments about addressing in documentation > jgroups-channel cannot use name which is already used by jgroups/stacks > ----------------------------------------------------------------------- > > Key: WFLY-9854 > URL: https://issues.jboss.org/browse/WFLY-9854 > Project: WildFly > Issue Type: Bug > Components: Clustering, JMS > Affects Versions: 12.0.0.Beta1 > Reporter: Erich Duda > Assignee: Paul Ferraro > Priority: Blocker > > The configuration \[1\] results to an error \[2\]. This is backward compatibility issue since the configuration works with previous releases of Wildfly. > \[1\] > {code:xml} > <broadcast-group name="bg-group1" jgroups-stack="udp" jgroups-channel="udp" broadcast-period="2000" connectors="connector"/> > {code} > \[2\] > {code} > 10:52:29,982 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "jgroups"), > ("channel" => "udp") > ]) - failure description: "WFLYCTL0436: Cannot register capability 'org.wildfly.clustering.jgroups.channel-factory.udp' at location '[ > (\"subsystem\" => \"jgroups\"), > (\"channel\" => \"udp\") > ]' as it is already registered in context 'global' at location(s) '[[ > (\"subsystem\" => \"jgroups\"), > (\"stack\" => \"udp\") > ]]'" > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 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 February 2018