May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12095) Use HTTPS and only HTTPS for management interfaces in default configuration

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-12095?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFLY-12095: ------------------------------------ Component/s: Security > Use HTTPS and only HTTPS for management interfaces in default configuration > --------------------------------------------------------------------------- > > Key: WFLY-12095 > URL: https://issues.jboss.org/browse/WFLY-12095 > Project: WildFly > Issue Type: Enhancement > Components: Management, Security > Affects Versions: 16.0.0.Final > Reporter: Jan Stourac > Assignee: Darran Lofthouse > Priority: Major > > Current default configuration of WildFly uses plaintext HTTP for management interfaces that are used for web-console access. Even though, that it is possible to switch to HTTPS after login to web-console, I believe we should incorporate HTTPS and only HTTPS configuration of management interfaces in our default WildFly configuration. > Note that there is digest-auth used for web-console login, thus password is not sent in a plain-text over the network, although there is still possibility of MITM attack, as such one can see what management operations are performed (actual request payload is binary, although I presume that it is easy to decode when one knows how to do it). > Yes, I understand that by default, there will be just a self-signed certificate generated for server on first HTTPS request, but I believe it is still an improvement. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12095) Use HTTPS and only HTTPS for management interfaces in default configuration

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-12095?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFLY-12095: --------------------------------------- Assignee: Darran Lofthouse (was: Jeff Mesnil) > Use HTTPS and only HTTPS for management interfaces in default configuration > --------------------------------------------------------------------------- > > Key: WFLY-12095 > URL: https://issues.jboss.org/browse/WFLY-12095 > Project: WildFly > Issue Type: Enhancement > Components: Management > Affects Versions: 16.0.0.Final > Reporter: Jan Stourac > Assignee: Darran Lofthouse > Priority: Major > > Current default configuration of WildFly uses plaintext HTTP for management interfaces that are used for web-console access. Even though, that it is possible to switch to HTTPS after login to web-console, I believe we should incorporate HTTPS and only HTTPS configuration of management interfaces in our default WildFly configuration. > Note that there is digest-auth used for web-console login, thus password is not sent in a plain-text over the network, although there is still possibility of MITM attack, as such one can see what management operations are performed (actual request payload is binary, although I presume that it is easy to decode when one knows how to do it). > Yes, I understand that by default, there will be just a self-signed certificate generated for server on first HTTPS request, but I believe it is still an improvement. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4048) DMN decision service invocation as literal expression typecheck

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-4048: -------------------------------------- Summary: DMN decision service invocation as literal expression typecheck Key: DROOLS-4048 URL: https://issues.jboss.org/browse/DROOLS-4048 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3903) DMN Submarine endpoint codegen

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3903?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-3903: ----------------------------------- Sprint: 2019 Week 23-25 (was: 2019 Week 20-22) > DMN Submarine endpoint codegen > ------------------------------ > > Key: DROOLS-3903 > URL: https://issues.jboss.org/browse/DROOLS-3903 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12096) Do not use hardcoded name to point to the provisioned server dist module

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFLY-12096?page=com.atlassian.jira.plugin... ] Yeray Borges updated WFLY-12096: -------------------------------- Affects Version/s: 17.0.0.Alpha1 > Do not use hardcoded name to point to the provisioned server dist module > ------------------------------------------------------------------------ > > Key: WFLY-12096 > URL: https://issues.jboss.org/browse/WFLY-12096 > Project: WildFly > Issue Type: Task > Components: Build System > Affects Versions: 17.0.0.Alpha1 > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Major > > 'jboss.actual.dist' is used in XSDValidationUnitTestCase and currently under dist module, it is using a hardcoded name to point to the provisioned server used in the test. > We should use a non-hardcoded name there to facilitate the transition to product branches, for example: > target/${server.output.dir.prefix}-${server.output.dir.version} > or > ${basedir}/target/${project.build.finalName} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12096) Do not use hardcoded name to point to the provisioned server dist module

by Yeray Borges (Jira)

Yeray Borges created WFLY-12096: ----------------------------------- Summary: Do not use hardcoded name to point to the provisioned server dist module Key: WFLY-12096 URL: https://issues.jboss.org/browse/WFLY-12096 Project: WildFly Issue Type: Task Components: Build System Reporter: Yeray Borges Assignee: Yeray Borges 'jboss.actual.dist' is used in XSDValidationUnitTestCase and currently under dist module, it is using a hardcoded name to point to the provisioned server used in the test. We should use a non-hardcoded name there to facilitate the transition to product branches, for example: target/${server.output.dir.prefix}-${server.output.dir.version} or ${basedir}/target/${project.build.finalName} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4039) Columns can be bound inappropriately

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-4039?page=com.atlassian.jira.plugi... ] Yeser Amer updated DROOLS-4039: ------------------------------- Story Points: 1 > Columns can be bound inappropriately > ------------------------------------- > > Key: DROOLS-4039 > URL: https://issues.jboss.org/browse/DROOLS-4039 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.22.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation > Attachments: bind-column.webm > > > There exist a way how user can bind scenario column inappropriately. For example property column of object A, can be bound to the property of totally different object. The way is shown in the attached video. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4039) Columns can be bound inappropriately

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-4039?page=com.atlassian.jira.plugi... ] Yeser Amer updated DROOLS-4039: ------------------------------- Sprint: 2019 Week 20-22 > Columns can be bound inappropriately > ------------------------------------- > > Key: DROOLS-4039 > URL: https://issues.jboss.org/browse/DROOLS-4039 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.22.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation > Attachments: bind-column.webm > > > There exist a way how user can bind scenario column inappropriately. For example property column of object A, can be bound to the property of totally different object. The way is shown in the attached video. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12095) Use HTTPS and only HTTPS for management interfaces in default configuration

by Jan Stourac (Jira)

Jan Stourac created WFLY-12095: ---------------------------------- Summary: Use HTTPS and only HTTPS for management interfaces in default configuration Key: WFLY-12095 URL: https://issues.jboss.org/browse/WFLY-12095 Project: WildFly Issue Type: Enhancement Components: Management Affects Versions: 16.0.0.Final Reporter: Jan Stourac Assignee: Jeff Mesnil Current default configuration of WildFly uses plaintext HTTP for management interfaces that are used for web-console access. Even though, that it is possible to switch to HTTPS after login to web-console, I believe we should incorporate HTTPS and only HTTPS configuration of management interfaces in our default WildFly configuration. Note that there is digest-auth used for web-console login, thus password is not sent in a plain-text over the network, although there is still possibility of MITM attack, as such one can see what management operations are performed (actual request payload is binary, although I presume that it is easy to decode when one knows how to do it). Yes, I understand that by default, there will be just a self-signed certificate generated for server on first HTTPS request, but I believe it is still an improvement. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on WFLY-12090: ----------------------------------------- [~flavia.rainone] I am wondering if WFTC should not be registering it's XAResourceRecovery implementation until the EJB services is started? https://github.com/jbosstm/jboss-transaction-spi/blob/master/src/main/jav... Or it should start up the EJB service and block in the XAResource::recover call? /cc [~mmusgrov] > Unknown service name jboss.ejb and txn > -------------------------------------- > > Key: WFLY-12090 > URL: https://issues.jboss.org/browse/WFLY-12090 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 17.0.0.Alpha1 > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > Fix For: 17.0.0.Beta1 > > > When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error: > {code} > 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429) > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn > ... 6 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

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 May 2019