[jira] [Resolved] (ARTEMIS-3790) Support masked passwords when creating connections
[ https://issues.apache.org/jira/browse/ARTEMIS-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-3790. - Resolution: Fixed > Support masked passwords when creating connections > -- > > Key: ARTEMIS-3790 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3790 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: API >Affects Versions: 2.19.1 >Reporter: Apache Dev >Assignee: Justin Bertram >Priority: Major > Fix For: 2.28.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > ActiveMQConnectionFactory#createConnection and similar APIs could accept > "masked" passwords. > This would improve usability in cases where connection password is already > stored in masked format. > For example, a client using TLS and username/password authentication would > need to configure the "trustStorePassword" in the brokerURL - which accepts > the ENC(...) form - and the connection password - currently not accepting the > ENC(...) form. > Accepting the masked password even for connection creation would improve > usability for clients storing masked passwords in configuration files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-3790) Support masked passwords when creating connections
[ https://issues.apache.org/jira/browse/ARTEMIS-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reopened ARTEMIS-3790: - Assignee: Justin Bertram > Support masked passwords when creating connections > -- > > Key: ARTEMIS-3790 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3790 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: API >Affects Versions: 2.19.1 >Reporter: Apache Dev >Assignee: Justin Bertram >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > ActiveMQConnectionFactory#createConnection and similar APIs could accept > "masked" passwords. > This would improve usability in cases where connection password is already > stored in masked format. > For example, a client using TLS and username/password authentication would > need to configure the "trustStorePassword" in the brokerURL - which accepts > the ENC(...) form - and the connection password - currently not accepting the > ENC(...) form. > Accepting the masked password even for connection creation would improve > usability for clients storing masked passwords in configuration files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-3790) Support masked passwords when creating connections
[ https://issues.apache.org/jira/browse/ARTEMIS-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-3790: Fix Version/s: 2.28.0 > Support masked passwords when creating connections > -- > > Key: ARTEMIS-3790 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3790 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: API >Affects Versions: 2.19.1 >Reporter: Apache Dev >Assignee: Justin Bertram >Priority: Major > Fix For: 2.28.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > ActiveMQConnectionFactory#createConnection and similar APIs could accept > "masked" passwords. > This would improve usability in cases where connection password is already > stored in masked format. > For example, a client using TLS and username/password authentication would > need to configure the "trustStorePassword" in the brokerURL - which accepts > the ENC(...) form - and the connection password - currently not accepting the > ENC(...) form. > Accepting the masked password even for connection creation would improve > usability for clients storing masked passwords in configuration files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[
https://issues.apache.org/jira/browse/ARTEMIS-4238?focusedWorklogId=860815=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860815
]
ASF GitHub Bot logged work on ARTEMIS-4238:
---
Author: ASF GitHub Bot
Created on: 05/May/23 19:13
Start Date: 05/May/23 19:13
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4435:
URL: https://github.com/apache/activemq-artemis/pull/4435#discussion_r1186424827
##
artemis-ra/src/main/java/org/apache/activemq/artemis/ra/inflow/ActiveMQActivationSpec.java:
##
@@ -120,6 +120,7 @@ public class ActiveMQActivationSpec extends
ConnectionFactoryProperties implemen
/**
* Transaction timeout
*/
+ @Deprecated
Review Comment:
Done.
##
artemis-ra/src/main/java/org/apache/activemq/artemis/ra/inflow/ActiveMQActivationSpec.java:
##
@@ -631,6 +632,7 @@ public Integer getTransactionTimeout() {
*
* @param value The value
*/
+ @Deprecated
Review Comment:
Ditto
Issue Time Tracking
---
Worklog Id: (was: 860815)
Time Spent: 1h 40m (was: 1.5h)
> transaction timeout ActivationConfigProperty is no longer working
> -
>
> Key: ARTEMIS-4238
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4238
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.28.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> ARTEMIS-3707 has created a regression where the transactionTimeout
> ActivationConfigProperty is no longer working properly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4265) Make more web console tabs conditional on permission
[
https://issues.apache.org/jira/browse/ARTEMIS-4265?focusedWorklogId=860812=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860812
]
ASF GitHub Bot logged work on ARTEMIS-4265:
---
Author: ASF GitHub Bot
Created on: 05/May/23 18:12
Start Date: 05/May/23 18:12
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4460:
URL: https://github.com/apache/activemq-artemis/pull/4460#discussion_r1186377047
##
tests/smoke-tests/src/test/java/org/apache/activemq/artemis/tests/smoke/console/QueuesTest.java:
##
@@ -60,6 +62,89 @@ public void testDefaultQueues() throws Exception {
assertEquals(0, queuesPage.getMessagesCount("ExpiryQueue"));
}
+ @Test
+ public void testConnectionsTab() {
Review Comment:
Done.
Issue Time Tracking
---
Worklog Id: (was: 860812)
Time Spent: 1h 10m (was: 1h)
> Make more web console tabs conditional on permission
>
>
> Key: ARTEMIS-4265
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4265
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Many of the tabs on the web console show up even though the user doesn't have
> permission to execute the command corresponding to the tab. For example the
> "Connections" tab shows up even though the user can't execute the
> {{listConnections}} management operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4212) Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
[
https://issues.apache.org/jira/browse/ARTEMIS-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719950#comment-17719950
]
ASF subversion and git services commented on ARTEMIS-4212:
--
Commit 5e32a1ab628cdc2d34cba2e92ca1a8465aa9a151 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=5e32a1ab62 ]
ARTEMIS-4212 add compatibility tests
> Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
> ---
>
> Key: ARTEMIS-4212
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4212
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> When the routing type of an address (and associated queue) does not match the
> routing type of a client producer, the resultant behavior is a bit unexpected.
> Expected Behavior:
> If a client sends a message to an address / queue with the same name, but a
> different routing type, the expected behavior would be to throw some sort of
> InvalidDestinationException (if auto-create is not enabled), or to create the
> matching address and queue with the appropriate routing type. The routing
> count on the existing address (with non-matching routing type) should remain
> unchanged.
> Actual Behavior:
> When sending, for example, to a predefined anycast address and queue from a
> multiccast (Topic) producer, the routed count on the address is incremented,
> but the message count on the matching queue is not. No indication is given at
> the client end that the messages failed to get routed - they are silently
> dropped.
> This is reproducible using a qpid / proton queue producer to send to a
> multicast address or using a topic producer to send to an anycast address,
> e.g.:
> 1. Create a a broker, setting auto-create-queues and auto-create addresses to
> "false" for the catch-all address-setting
> 2. Start the broker and create a an address and matching queue with a ANYCAST
> routing type
> 3. Send 1000 messages to the broker using the same queue name but mismatched
> routing type:
> {code}
> ./artemis producer --url amqp://localhost:61616 --user admin --password admin
> --destination topic://{QUEUE NAME} --protocol amqp
> {code}
> No error is emitted and the routing count is incremented by 1000 at the
> address level, but remains unchanged at the destination level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4212) Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
[
https://issues.apache.org/jira/browse/ARTEMIS-4212?focusedWorklogId=860811=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860811
]
ASF GitHub Bot logged work on ARTEMIS-4212:
---
Author: ASF GitHub Bot
Created on: 05/May/23 18:10
Start Date: 05/May/23 18:10
Worklog Time Spent: 10m
Work Description: clebertsuconic merged PR #4467:
URL: https://github.com/apache/activemq-artemis/pull/4467
Issue Time Tracking
---
Worklog Id: (was: 860811)
Time Spent: 6h 50m (was: 6h 40m)
> Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
> ---
>
> Key: ARTEMIS-4212
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4212
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> When the routing type of an address (and associated queue) does not match the
> routing type of a client producer, the resultant behavior is a bit unexpected.
> Expected Behavior:
> If a client sends a message to an address / queue with the same name, but a
> different routing type, the expected behavior would be to throw some sort of
> InvalidDestinationException (if auto-create is not enabled), or to create the
> matching address and queue with the appropriate routing type. The routing
> count on the existing address (with non-matching routing type) should remain
> unchanged.
> Actual Behavior:
> When sending, for example, to a predefined anycast address and queue from a
> multiccast (Topic) producer, the routed count on the address is incremented,
> but the message count on the matching queue is not. No indication is given at
> the client end that the messages failed to get routed - they are silently
> dropped.
> This is reproducible using a qpid / proton queue producer to send to a
> multicast address or using a topic producer to send to an anycast address,
> e.g.:
> 1. Create a a broker, setting auto-create-queues and auto-create addresses to
> "false" for the catch-all address-setting
> 2. Start the broker and create a an address and matching queue with a ANYCAST
> routing type
> 3. Send 1000 messages to the broker using the same queue name but mismatched
> routing type:
> {code}
> ./artemis producer --url amqp://localhost:61616 --user admin --password admin
> --destination topic://{QUEUE NAME} --protocol amqp
> {code}
> No error is emitted and the routing count is incremented by 1000 at the
> address level, but remains unchanged at the destination level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860810=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860810
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 05/May/23 17:55
Start Date: 05/May/23 17:55
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1186363513
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,9 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ logger.debug("Handling LoginException with
NoCacheLoginException root cause", e);
Review Comment:
I just pushed with this update.
Issue Time Tracking
---
Worklog Id: (was: 860810)
Time Spent: 3h (was: 2h 50m)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4212) Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
[
https://issues.apache.org/jira/browse/ARTEMIS-4212?focusedWorklogId=860804=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860804
]
ASF GitHub Bot logged work on ARTEMIS-4212:
---
Author: ASF GitHub Bot
Created on: 05/May/23 17:04
Start Date: 05/May/23 17:04
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request, #4467:
URL: https://github.com/apache/activemq-artemis/pull/4467
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 860804)
Time Spent: 6h 40m (was: 6.5h)
> Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
> ---
>
> Key: ARTEMIS-4212
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4212
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> When the routing type of an address (and associated queue) does not match the
> routing type of a client producer, the resultant behavior is a bit unexpected.
> Expected Behavior:
> If a client sends a message to an address / queue with the same name, but a
> different routing type, the expected behavior would be to throw some sort of
> InvalidDestinationException (if auto-create is not enabled), or to create the
> matching address and queue with the appropriate routing type. The routing
> count on the existing address (with non-matching routing type) should remain
> unchanged.
> Actual Behavior:
> When sending, for example, to a predefined anycast address and queue from a
> multiccast (Topic) producer, the routed count on the address is incremented,
> but the message count on the matching queue is not. No indication is given at
> the client end that the messages failed to get routed - they are silently
> dropped.
> This is reproducible using a qpid / proton queue producer to send to a
> multicast address or using a topic producer to send to an anycast address,
> e.g.:
> 1. Create a a broker, setting auto-create-queues and auto-create addresses to
> "false" for the catch-all address-setting
> 2. Start the broker and create a an address and matching queue with a ANYCAST
> routing type
> 3. Send 1000 messages to the broker using the same queue name but mismatched
> routing type:
> {code}
> ./artemis producer --url amqp://localhost:61616 --user admin --password admin
> --destination topic://{QUEUE NAME} --protocol amqp
> {code}
> No error is emitted and the routing count is incremented by 1000 at the
> address level, but remains unchanged at the destination level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860801=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860801
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 05/May/23 16:40
Start Date: 05/May/23 16:40
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1186293356
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,9 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ logger.debug("Handling LoginException with
NoCacheLoginException root cause", e);
Review Comment:
We don't need a new interface because classes implementing an interface
don't have to throw exceptions defined in the interface. So current
implementations of ActiveMQSecurityManager5 will work also if we add `throws
NoCacheLoginException` to the `authenticate` method of
`ActiveMQSecurityManager5`.
Issue Time Tracking
---
Worklog Id: (was: 860801)
Time Spent: 2h 50m (was: 2h 40m)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860798=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860798
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 05/May/23 16:37
Start Date: 05/May/23 16:37
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1186293356
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,9 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ logger.debug("Handling LoginException with
NoCacheLoginException root cause", e);
Review Comment:
We don't need a new interface because classes implementing an interface
don't have to throw exceptions defined in the interface. So current
implementations of ActiveMQSecurityManager5 will work also if we add the trwows
NoCacheLoginException to the `authenticate` method of
`ActiveMQSecurityManager5`.
Issue Time Tracking
---
Worklog Id: (was: 860798)
Time Spent: 2h 40m (was: 2.5h)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860796=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860796
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 05/May/23 16:36
Start Date: 05/May/23 16:36
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1186293356
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,9 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ logger.debug("Handling LoginException with
NoCacheLoginException root cause", e);
Review Comment:
We don't need a new interface because classes implementing an interface
don't have to throw exceptions defined in the interface. So current
implementations of ActiveMQSecurityManager5 will work also if we add the trwows
NoCacheLoginException to the `authenticate` method.
Issue Time Tracking
---
Worklog Id: (was: 860796)
Time Spent: 2.5h (was: 2h 20m)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860795=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860795
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 05/May/23 16:35
Start Date: 05/May/23 16:35
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1186293356
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,9 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ logger.debug("Handling LoginException with
NoCacheLoginException root cause", e);
Review Comment:
We don't need a new interface because class implementing an interface don't
have to throw exceptions defined in the interface.
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,9 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ logger.debug("Handling LoginException with
NoCacheLoginException root cause", e);
Review Comment:
We don't need a new interface because classes implementing an interface
don't have to throw exceptions defined in the interface.
Issue Time Tracking
---
Worklog Id: (was: 860795)
Time Spent: 2h 20m (was: 2h 10m)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860794=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860794
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 05/May/23 16:27
Start Date: 05/May/23 16:27
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1186286615
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,9 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ logger.debug("Handling LoginException with
NoCacheLoginException root cause", e);
Review Comment:
I considered that approach originally, but I would have to add a new
interface (e.g. `ActiveMQSecurityManager6`) where `authenticate` could throw a
checked exception. The security manager is pluggable and some users implement
their own so we can't just change the interface.
Issue Time Tracking
---
Worklog Id: (was: 860794)
Time Spent: 2h 10m (was: 2h)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3042) Official Docker Multistage Build as well as an official Docker image.
[ https://issues.apache.org/jira/browse/ARTEMIS-3042?focusedWorklogId=860746=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860746 ] ASF GitHub Bot logged work on ARTEMIS-3042: --- Author: ASF GitHub Bot Created on: 05/May/23 12:20 Start Date: 05/May/23 12:20 Worklog Time Spent: 10m Work Description: gemmellr commented on code in PR #4297: URL: https://github.com/apache/activemq-artemis/pull/4297#discussion_r1186022466 ## pom.xml: ## @@ -68,6 +68,7 @@ artemis-features artemis-quorum-api artemis-quorum-ri + artemis-image Review Comment: Probably wouldnt want this to be building on every build, so maybe shift to release profile (needs to be enabled then to update the versions) ## artemis-image/pom.xml: ## @@ -0,0 +1,127 @@ + + +http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;> + 4.0.0 + + + org.apache.activemq + artemis-pom + 2.28.0-SNAPSHOT + + + artemis-image + Apache ActiveMQ Artemis Image + + + Official Docker Multistage Build as well as an official Docker image. > - > > Key: ARTEMIS-3042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3042 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: John Behm >Priority: Minor > Labels: docker,, dockerfile,, kubernetes > Time Spent: 7h 40m > Remaining Estimate: 0h > > It would be rather convenient to get people up and running with an easy to > build or to setup Docker image that automatically builds the project from > source, discards the build container and moves the necessary files over to > the final container that can simply be started. > The current docker image build is not really user firendly or convenient at > all. > > https://github.com/apache/activemq-artemis/tree/master/artemis-docker > The whole setup process of artemis in a containerized environment is very > far from even good. > The hurdle of using this software is gigantic, as the configuration is so > complex, one will not be able to do this within one month without having gone > through the whole documentation multiple times. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860732=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860732
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 05/May/23 11:25
Start Date: 05/May/23 11:25
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1185981084
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,9 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ logger.debug("Handling LoginException with
NoCacheLoginException root cause", e);
Review Comment:
@jbertram thanks for pointing me to the reason of the current
implementation. If I understand correctly JAAS converts NoCacheLoginException
into LoginException because NoCacheLoginException is not a subclass of
LoginException.
If NoCacheLoginException would inherit from LoginException and
ActiveMQSecurityManager5.authenticate would throw LoginException we could avoid
to set and check the root cause, we could just throw and catch
NoCacheLoginException. Is that right?
Issue Time Tracking
---
Worklog Id: (was: 860732)
Time Spent: 2h (was: 1h 50m)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4256) properties config - support removal
[ https://issues.apache.org/jira/browse/ARTEMIS-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4256. - Fix Version/s: 2.29.0 Resolution: Fixed > properties config - support removal > --- > > Key: ARTEMIS-4256 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4256 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > > broker properties allow addition and modification of configuration elements > through property key=values but don't current allow an entry to be removed. > > When used as part of configuration reload, being able to delete is useful! > maybe a key value with some special value is the way to signal to remove that > entry. > > addressConfigurations.COMMANDS=- > in this case the minus char '-' means remove the address called COMMANDS > =- seems nice, allowing the remove value to be configured by a property > remove.value makes sense too in case - is a valid value. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4256) properties config - support removal
[ https://issues.apache.org/jira/browse/ARTEMIS-4256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719802#comment-17719802 ] ASF subversion and git services commented on ARTEMIS-4256: -- Commit c5d872575e5ed08a3d5d13e6bcdac8eaf230e0b1 in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c5d872575e ] ARTEMIS-4256 - support removal of configuration via properties > properties config - support removal > --- > > Key: ARTEMIS-4256 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4256 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > broker properties allow addition and modification of configuration elements > through property key=values but don't current allow an entry to be removed. > > When used as part of configuration reload, being able to delete is useful! > maybe a key value with some special value is the way to signal to remove that > entry. > > addressConfigurations.COMMANDS=- > in this case the minus char '-' means remove the address called COMMANDS > =- seems nice, allowing the remove value to be configured by a property > remove.value makes sense too in case - is a valid value. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4256) properties config - support removal
[ https://issues.apache.org/jira/browse/ARTEMIS-4256?focusedWorklogId=860729=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860729 ] ASF GitHub Bot logged work on ARTEMIS-4256: --- Author: ASF GitHub Bot Created on: 05/May/23 10:58 Start Date: 05/May/23 10:58 Worklog Time Spent: 10m Work Description: gtully merged PR #4466: URL: https://github.com/apache/activemq-artemis/pull/4466 Issue Time Tracking --- Worklog Id: (was: 860729) Time Spent: 40m (was: 0.5h) > properties config - support removal > --- > > Key: ARTEMIS-4256 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4256 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > broker properties allow addition and modification of configuration elements > through property key=values but don't current allow an entry to be removed. > > When used as part of configuration reload, being able to delete is useful! > maybe a key value with some special value is the way to signal to remove that > entry. > > addressConfigurations.COMMANDS=- > in this case the minus char '-' means remove the address called COMMANDS > =- seems nice, allowing the remove value to be configured by a property > remove.value makes sense too in case - is a valid value. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4256) properties config - support removal
[
https://issues.apache.org/jira/browse/ARTEMIS-4256?focusedWorklogId=860726=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860726
]
ASF GitHub Bot logged work on ARTEMIS-4256:
---
Author: ASF GitHub Bot
Created on: 05/May/23 10:49
Start Date: 05/May/23 10:49
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4466:
URL: https://github.com/apache/activemq-artemis/pull/4466#discussion_r1185953053
##
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/config/ActiveMQDefaultConfiguration.java:
##
@@ -569,8 +569,12 @@ public static String getDefaultHapolicyBackupStrategy() {
public static final String BROKER_PROPERTIES_KEY_SURROUND = "\"";
+ public static final String BROKER_PROPERTIES_REMOVE_VALUE = "-";
Review Comment:
I see, good point!
Issue Time Tracking
---
Worklog Id: (was: 860726)
Time Spent: 0.5h (was: 20m)
> properties config - support removal
> ---
>
> Key: ARTEMIS-4256
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4256
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration
>Affects Versions: 2.28.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> broker properties allow addition and modification of configuration elements
> through property key=values but don't current allow an entry to be removed.
>
> When used as part of configuration reload, being able to delete is useful!
> maybe a key value with some special value is the way to signal to remove that
> entry.
>
> addressConfigurations.COMMANDS=-
> in this case the minus char '-' means remove the address called COMMANDS
> =- seems nice, allowing the remove value to be configured by a property
> remove.value makes sense too in case - is a valid value.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4256) properties config - support removal
[
https://issues.apache.org/jira/browse/ARTEMIS-4256?focusedWorklogId=860709=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860709
]
ASF GitHub Bot logged work on ARTEMIS-4256:
---
Author: ASF GitHub Bot
Created on: 05/May/23 09:05
Start Date: 05/May/23 09:05
Worklog Time Spent: 10m
Work Description: gtully commented on code in PR #4466:
URL: https://github.com/apache/activemq-artemis/pull/4466#discussion_r1185862241
##
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/config/ActiveMQDefaultConfiguration.java:
##
@@ -569,8 +569,12 @@ public static String getDefaultHapolicyBackupStrategy() {
public static final String BROKER_PROPERTIES_KEY_SURROUND = "\"";
+ public static final String BROKER_PROPERTIES_REMOVE_VALUE = "-";
Review Comment:
interesting, thanks for the link. This is exactly the sort of thing we
should be aware of and follow, convention over configuration etc.
However, in this case, I think the semantic of that is a little different,
it is a null value, where the key still exists. x=null
x=- means remove x.
I am not sure if there is any case in artemis config where we want to have a
collection with a null entry.
Issue Time Tracking
---
Worklog Id: (was: 860709)
Time Spent: 20m (was: 10m)
> properties config - support removal
> ---
>
> Key: ARTEMIS-4256
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4256
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration
>Affects Versions: 2.28.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> broker properties allow addition and modification of configuration elements
> through property key=values but don't current allow an entry to be removed.
>
> When used as part of configuration reload, being able to delete is useful!
> maybe a key value with some special value is the way to signal to remove that
> entry.
>
> addressConfigurations.COMMANDS=-
> in this case the minus char '-' means remove the address called COMMANDS
> =- seems nice, allowing the remove value to be configured by a property
> remove.value makes sense too in case - is a valid value.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4263) support access to our JaasCallbackhandler from a jdk http Authenticator
[
https://issues.apache.org/jira/browse/ARTEMIS-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719756#comment-17719756
]
ASF subversion and git services commented on ARTEMIS-4263:
--
Commit cf3afc409683b8d279fe7bb3cd4c32ce6b8fdb98 in activemq-artemis's branch
refs/heads/main from Gary Tully
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=cf3afc4096 ]
ARTEMIS-4263 authenticator to delegate to artemis jaas login modules and
populate callback handler
> support access to our JaasCallbackhandler from a jdk http Authenticator
> ---
>
> Key: ARTEMIS-4263
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4263
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: JAAS
>Affects Versions: 2.28.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> To allow the jolokia jvm agent to utilise jaas with our callback handler, it
> is necessary to provide a wrapper that is aware of the capabilities of the
> various artemis login modules and provide the necessary callback
> implementation
> httpserver supports an extension point in the form of a
> {{com.sun.net.httpserver.Authenticator}} that we can use. the jolokia jvm
> agent has an authenticator that does jaas but is limited to plain
> credentials. We can plug in a similar Artemis jaas delegating authenticator
> and do proper rbac when the jolokia jvm agent is in play.
> This will allow us to reduce the surface are that we expose to support
> jolokia, avoiding the need for jetty.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4263) support access to our JaasCallbackhandler from a jdk http Authenticator
[
https://issues.apache.org/jira/browse/ARTEMIS-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved ARTEMIS-4263.
-
Fix Version/s: 2.29.0
Resolution: Fixed
> support access to our JaasCallbackhandler from a jdk http Authenticator
> ---
>
> Key: ARTEMIS-4263
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4263
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: JAAS
>Affects Versions: 2.28.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> To allow the jolokia jvm agent to utilise jaas with our callback handler, it
> is necessary to provide a wrapper that is aware of the capabilities of the
> various artemis login modules and provide the necessary callback
> implementation
> httpserver supports an extension point in the form of a
> {{com.sun.net.httpserver.Authenticator}} that we can use. the jolokia jvm
> agent has an authenticator that does jaas but is limited to plain
> credentials. We can plug in a similar Artemis jaas delegating authenticator
> and do proper rbac when the jolokia jvm agent is in play.
> This will allow us to reduce the surface are that we expose to support
> jolokia, avoiding the need for jetty.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4263) support access to our JaasCallbackhandler from a jdk http Authenticator
[
https://issues.apache.org/jira/browse/ARTEMIS-4263?focusedWorklogId=860707=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860707
]
ASF GitHub Bot logged work on ARTEMIS-4263:
---
Author: ASF GitHub Bot
Created on: 05/May/23 09:00
Start Date: 05/May/23 09:00
Worklog Time Spent: 10m
Work Description: gtully merged PR #4458:
URL: https://github.com/apache/activemq-artemis/pull/4458
Issue Time Tracking
---
Worklog Id: (was: 860707)
Time Spent: 2h 20m (was: 2h 10m)
> support access to our JaasCallbackhandler from a jdk http Authenticator
> ---
>
> Key: ARTEMIS-4263
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4263
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: JAAS
>Affects Versions: 2.28.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> To allow the jolokia jvm agent to utilise jaas with our callback handler, it
> is necessary to provide a wrapper that is aware of the capabilities of the
> various artemis login modules and provide the necessary callback
> implementation
> httpserver supports an extension point in the form of a
> {{com.sun.net.httpserver.Authenticator}} that we can use. the jolokia jvm
> agent has an authenticator that does jaas but is limited to plain
> credentials. We can plug in a similar Artemis jaas delegating authenticator
> and do proper rbac when the jolokia jvm agent is in play.
> This will allow us to reduce the surface are that we expose to support
> jolokia, avoiding the need for jetty.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4265) Make more web console tabs conditional on permission
[
https://issues.apache.org/jira/browse/ARTEMIS-4265?focusedWorklogId=860703=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860703
]
ASF GitHub Bot logged work on ARTEMIS-4265:
---
Author: ASF GitHub Bot
Created on: 05/May/23 08:41
Start Date: 05/May/23 08:41
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4460:
URL: https://github.com/apache/activemq-artemis/pull/4460#discussion_r1185840593
##
tests/smoke-tests/src/test/java/org/apache/activemq/artemis/tests/smoke/console/QueuesTest.java:
##
@@ -60,6 +62,89 @@ public void testDefaultQueues() throws Exception {
assertEquals(0, queuesPage.getMessagesCount("ExpiryQueue"));
}
+ @Test
+ public void testConnectionsTab() {
Review Comment:
Nice tests but they don't seem related to queues, could you move them to a
new test class, i.e. `TabsTest` or any other names?
##
tests/smoke-tests/src/test/java/org/apache/activemq/artemis/tests/smoke/console/QueuesTest.java:
##
@@ -60,6 +62,89 @@ public void testDefaultQueues() throws Exception {
assertEquals(0, queuesPage.getMessagesCount("ExpiryQueue"));
}
+ @Test
+ public void testConnectionsTab() {
Review Comment:
Nice tests but they don't seem related to queues, could you move them to a
new test class, i.e. `TabsTest` or any other names?
Issue Time Tracking
---
Worklog Id: (was: 860703)
Time Spent: 1h (was: 50m)
> Make more web console tabs conditional on permission
>
>
> Key: ARTEMIS-4265
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4265
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Many of the tabs on the web console show up even though the user doesn't have
> permission to execute the command corresponding to the tab. For example the
> "Connections" tab shows up even though the user can't execute the
> {{listConnections}} management operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
