[jira] [Commented] (QPID-8648) [Broker-J] Allow for max frame size >4096 before Open frame (SASL)
[
https://issues.apache.org/jira/browse/QPID-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811852#comment-17811852
]
ASF GitHub Bot commented on QPID-8648:
--
vavrtom merged PR #234:
URL: https://github.com/apache/qpid-broker-j/pull/234
> [Broker-J] Allow for max frame size >4096 before Open frame (SASL)
> --
>
> Key: QPID-8648
> URL: https://issues.apache.org/jira/browse/QPID-8648
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-9.0.0
>Reporter: Dan Langford
>Priority: Major
> Fix For: qpid-java-broker-9.1.1
>
>
> some modern authentication options (XOAUTH2 + JWT) require frames larger then
> 4096. consider if the max frame size (before an Open frame negotiation)
> should be larger or should be configurable with some sort of configuration or
> env variable.
>
> from a discussion on the mailing list
> {quote}The SASL process occurs first, before the Open frame. The Open frames
> are what carries each peers advertised max frame size, mainly aimed at
> later message deliveries. The AMQP 1.0 spec defines before this
> however that the SASL frames can be at-most the 'min max frame size',
> which is fixed at 512 bytes, with no way to negotiate anything larger.
> As you can probably tell, that presents a problem if things in the
> SASL negotiation want to be larger, such as is likely in e.g a newer
> XOAUTH2 mechanism that didnt exist when that decision was originally
> made.
> To simply allow some of these newer alternative mechs to work, it was
> decided to just allow things to exceed the 512byte limit since both
> sides would have to already agree on using a given mech to begin with,
> so doing an alternative like creating a custom multi-challenge
> batching sequence to shuffle the bytes wasnt really going to be adding
> much except significant complexity.
> It appears broker-j allows up to 4096, and you have now found
> something to exceed even that. It doesnt look like it allows
> configuring it, but increasing that seems to be the only option that
> would help here.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8648) [Broker-J] Allow for max frame size >4096 before Open frame (SASL)
[
https://issues.apache.org/jira/browse/QPID-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811853#comment-17811853
]
ASF subversion and git services commented on QPID-8648:
---
Commit c88188678fb1e9b804cacf702507b28bbbf9d105 in qpid-broker-j's branch
refs/heads/main from Daniil Kirilyuk
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=c88188678f ]
QPID-8648: [Broker-J] Allow for max frame size >4096 before Open frame (SASL)
(#234)
> [Broker-J] Allow for max frame size >4096 before Open frame (SASL)
> --
>
> Key: QPID-8648
> URL: https://issues.apache.org/jira/browse/QPID-8648
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-9.0.0
>Reporter: Dan Langford
>Priority: Major
> Fix For: qpid-java-broker-9.1.1
>
>
> some modern authentication options (XOAUTH2 + JWT) require frames larger then
> 4096. consider if the max frame size (before an Open frame negotiation)
> should be larger or should be configurable with some sort of configuration or
> env variable.
>
> from a discussion on the mailing list
> {quote}The SASL process occurs first, before the Open frame. The Open frames
> are what carries each peers advertised max frame size, mainly aimed at
> later message deliveries. The AMQP 1.0 spec defines before this
> however that the SASL frames can be at-most the 'min max frame size',
> which is fixed at 512 bytes, with no way to negotiate anything larger.
> As you can probably tell, that presents a problem if things in the
> SASL negotiation want to be larger, such as is likely in e.g a newer
> XOAUTH2 mechanism that didnt exist when that decision was originally
> made.
> To simply allow some of these newer alternative mechs to work, it was
> decided to just allow things to exceed the 512byte limit since both
> sides would have to already agree on using a given mech to begin with,
> so doing an alternative like creating a custom multi-challenge
> batching sequence to shuffle the bytes wasnt really going to be adding
> much except significant complexity.
> It appears broker-j allows up to 4096, and you have now found
> something to exceed even that. It doesnt look like it allows
> configuring it, but increasing that seems to be the only option that
> would help here.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8648) [Broker-J] Allow for max frame size >4096 before Open frame (SASL)
[
https://issues.apache.org/jira/browse/QPID-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810245#comment-17810245
]
ASF GitHub Bot commented on QPID-8648:
--
dakirily opened a new pull request, #234:
URL: https://github.com/apache/qpid-broker-j/pull/234
This PR addresses JIRA
[QPID-8648](https://issues.apache.org/jira/browse/QPID-8648), increasing
maximal frame size before Open frame during SASL negotiation
> [Broker-J] Allow for max frame size >4096 before Open frame (SASL)
> --
>
> Key: QPID-8648
> URL: https://issues.apache.org/jira/browse/QPID-8648
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-9.0.0
>Reporter: Dan Langford
>Priority: Major
> Fix For: qpid-java-broker-9.1.1
>
>
> some modern authentication options (XOAUTH2 + JWT) require frames larger then
> 4096. consider if the max frame size (before an Open frame negotiation)
> should be larger or should be configurable with some sort of configuration or
> env variable.
>
> from a discussion on the mailing list
> {quote}The SASL process occurs first, before the Open frame. The Open frames
> are what carries each peers advertised max frame size, mainly aimed at
> later message deliveries. The AMQP 1.0 spec defines before this
> however that the SASL frames can be at-most the 'min max frame size',
> which is fixed at 512 bytes, with no way to negotiate anything larger.
> As you can probably tell, that presents a problem if things in the
> SASL negotiation want to be larger, such as is likely in e.g a newer
> XOAUTH2 mechanism that didnt exist when that decision was originally
> made.
> To simply allow some of these newer alternative mechs to work, it was
> decided to just allow things to exceed the 512byte limit since both
> sides would have to already agree on using a given mech to begin with,
> so doing an alternative like creating a custom multi-challenge
> batching sequence to shuffle the bytes wasnt really going to be adding
> much except significant complexity.
> It appears broker-j allows up to 4096, and you have now found
> something to exceed even that. It doesnt look like it allows
> configuring it, but increasing that seems to be the only option that
> would help here.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
