[jira] [Commented] (PROTON-2347) Reactor leaks file handles when an IO Exception is encountered
[ https://issues.apache.org/jira/browse/PROTON-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303671#comment-17303671 ] Tim Taylor commented on PROTON-2347: My apologies for the duplicate issues that I filed. The Jira GUI displayed some odd exceptions when I tried to file the first few issues, so I thought they weren't created. > Reactor leaks file handles when an IO Exception is encountered > -- > > Key: PROTON-2347 > URL: https://issues.apache.org/jira/browse/PROTON-2347 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: proton-j-0.33.8 > Environment: Windows 10 desktop >Reporter: Tim Taylor >Priority: Minor > Fix For: proton-j-future > > Attachments: repro.txt > > > When I try to open a connection using proton-j while my machine doesn't have > internet access, I see that proton-j leaks file descriptors. Attached is the > sample I wrote that repro's this issue. I'm looking either for guidance on > how to handle IOExceptions in the onTransportError callback, or for a > confirmation that what I'm doing to handle them is correct, and that there is > a bug in proton-j around this scenario. > > If you need help viewing the file descriptor count growing over time, the > [process explorer > tool|https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer] > is what I've been using. Running the sample in a loop will make this leak > more obvious, but it isn't required to leak the file descriptors. This same > bug seems to happen in Linux and MacOS as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2349) [Proton-j] Reactor leaks file descriptors when IOException is encountered
Tim Taylor created PROTON-2349: -- Summary: [Proton-j] Reactor leaks file descriptors when IOException is encountered Key: PROTON-2349 URL: https://issues.apache.org/jira/browse/PROTON-2349 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: proton-j-0.33.8 Environment: Windows 10 Reporter: Tim Taylor Fix For: proton-j-future Attachments: repro.txt When I run some simple proton-j code to open a connection while my machine has no internet access, proton-j appears to leak file descriptors. I have some code attached that you can use to repro this issue. You simply need to run the sample while your internet is disconnected. >From what I can tell, proton-j does not leak any file descriptors for >successful connections. I've been using Window's to [process explorer|https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer] view my machine's file descriptors over time. This same issue is present in Linux and MacOS as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2348) Proton-j leaks file descriptors when connection fails to open
Tim Taylor created PROTON-2348: -- Summary: Proton-j leaks file descriptors when connection fails to open Key: PROTON-2348 URL: https://issues.apache.org/jira/browse/PROTON-2348 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: proton-j-0.33.8 Environment: Windows 10 desktop Reporter: Tim Taylor Fix For: proton-j-future Attachments: repro.txt When I run some simple proton-j code to open a connection while my machine has no internet access, proton-j appears to leak file descriptors. I have some code attached that you can use to repro this issue. You simply need to run the sample while your internet is disconnected. >From what I can tell, proton-j does not leak any file descriptors for >successful connections. I've been using Window's to [process explorer|https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer] view my machine's file descriptors over time. This same issue is present in Linux and MacOS as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2347) Reactor leaks file handles when an IO Exception is encountered
Tim Taylor created PROTON-2347: -- Summary: Reactor leaks file handles when an IO Exception is encountered Key: PROTON-2347 URL: https://issues.apache.org/jira/browse/PROTON-2347 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: proton-j-0.33.8 Environment: Windows 10 desktop Reporter: Tim Taylor Fix For: proton-j-future Attachments: repro.txt When I try to open a connection using proton-j while my machine doesn't have internet access, I see that proton-j leaks file descriptors. Attached is the sample I wrote that repro's this issue. I'm looking either for guidance on how to handle IOExceptions in the onTransportError callback, or for a confirmation that what I'm doing to handle them is correct, and that there is a bug in proton-j around this scenario. If you need help viewing the file descriptor count growing over time, the [process explorer tool|https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer] is what I've been using. Running the sample in a loop will make this leak more obvious, but it isn't required to leak the file descriptors. This same bug seems to happen in Linux and MacOS as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318874#comment-16318874
]
Tim Taylor commented on PROTON-1718:
Great! Thanks again for your help with this!
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317320#comment-16317320
]
Tim Taylor commented on PROTON-1718:
This seems to work perfectly for us. Any ETA on when this might be released?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316785#comment-16316785
]
Tim Taylor commented on PROTON-1718:
This looks perfect, I'll try testing it out today!
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314060#comment-16314060
]
Tim Taylor commented on PROTON-1718:
Okay, thanks for looking into it. Keep me posted as this is becoming a blocking
issue for me.
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16311814#comment-16311814
]
Tim Taylor commented on PROTON-1718:
And if the only time the reactor does IO processing is when it receives an
event, when is the appropriate event to send the response? I've tried sending
the response at onReactorQuiesced(), onSelectableWritable(), etc. and none of
them seem to be the right time. Because the responses never make it to the
service.
So far, the only event that I can send upon and have it successfully sent to
the service is the handleChallenge() event within the SaslImpl, but you don't
want that to be accessible, so I'm stuck.
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16310063#comment-16310063
]
Tim Taylor edited comment on PROTON-1718 at 1/3/18 6:55 PM:
I want to set aside the talk of adding extra threads to this problem. I don't
think I will need to use separate threads for this scenario.
Instead, I want to drill down on part of your comment:
"When you 'send' for sasl (which doesnt actually send anything on the wire
immediately, only later when the IO processing occurs) is indeed important
since any IO work is only done explicitly at a stage of the thread processing
the reactor (which is often after processing received data off the wire)."
Is this the only time when the reactor does IO processing? I would like my
"send" calls to be processed, but there is no callback extended to the user
that allows them to react in time to catch the reactor in this phase. I would
imagine that there is some event that should be extended to users that allows
them to insert their challenge response when a given challenge is received.
Maybe it is one of the many BaseHandler events? Using sasl.Pending() isn't good
enough to catch the reactor during this IO phase.
Is there a way to tell the reactor to do IO processing at some arbitrary
reactor event (onReactorQuiesced, for example)?
was (Author: timtay):
I want to set aside the talk of adding extra threads to this problem. I don't
think I will need to use separate threads for this scenario.
Instead, I want to drill down on part of your comment:
"When you 'send' for sasl (which doesnt actually send anything on the wire
immediately, only later when the IO processing occurs) is indeed important
since any IO work is only done explicitly at a stage of the thread processing
the reactor (which is often after processing received data off the wire)."
Is this the only time when the reactor does IO processing? I would like my
"send" calls to be processed, but there is no callback extended to the user
that allows them to react in time to catch the reactor in this phase. I would
imagine that there is some event that should be extended to users that allows
them to insert their challenge response when a given challenge is received.
Using sasl.Pending() isn't good enough to catch the reactor during this IO
phase.
Is there a way to tell the reactor to do IO processing at some arbitrary
reactor event (onReactorQuiesced, for example)?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16310063#comment-16310063
]
Tim Taylor commented on PROTON-1718:
I want to set aside the talk of adding extra threads to this problem. I don't
think I will need to use separate threads for this scenario.
Instead, I want to drill down on part of your comment:
"When you 'send' for sasl (which doesnt actually send anything on the wire
immediately, only later when the IO processing occurs) is indeed important
since any IO work is only done explicitly at a stage of the thread processing
the reactor (which is often after processing received data off the wire)."
Is this the only time when the reactor does IO processing? I would like my
"send" calls to be processed, but there is no callback extended to the user
that allows them to react in time to catch the reactor in this phase. I would
imagine that there is some event that should be extended to users that allows
them to insert their challenge response when a given challenge is received.
Using sasl.Pending() isn't good enough to catch the reactor during this IO
phase.
Is there a way to tell the reactor to do IO processing at some arbitrary
reactor event (onReactorQuiesced, for example)?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16308528#comment-16308528
]
Tim Taylor commented on PROTON-1718:
I know that the service is functioning correctly in this scenario. When I
provide a custom Sasl implementation to be used instead of the usual SaslImpl
implementation, and I use the same init/challenge response data as above, the
flow works as intended. It seems like the timing for when you call
sasl.send(...) really matters because when I send the challenge response data
within the sasl.handleChallenge(...) event method, the response frame is
written immediately and I receive the next challenge correctly. When I try to
send the challenge response from a separate thread upon sasl.pending() being
non-zero, I get no response.
What am I doing wrong here?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301860#comment-16301860
]
Tim Taylor edited comment on PROTON-1718 at 12/22/17 7:33 PM:
--
Actually, after doing some digging, I suspect that I don't need to submit a PR
to achieve this functionality. If I understand the Sasl APIs correctly, I
should be able to use the combination of send(...)/recv(...)/pending() to
manually send inits, wait for challenges, receive those challenges, and send my
custom responses to meet the challenges. I can't seem to make it work, however.
I can successfully send the init frame and am given a challenge frame in
response. I can read that challenge frame just fine and can expose it to my
application just fine. However, when I try to send a response to that first
challenge, the frame I am trying to send is never written.
It is saved as the challenge response, but it is never processed beyond that.
Is the below code supposed to work for this custom sasl scenario?
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("");
//send init message, wait for response
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive first challenge, send first challenge response, wait for second
challenge
byte[] firstChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive second challenge, send second challenge response
byte[] secondChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
...
private void waitForSaslBuffer(Sasl sasl)
{
while (sasl.pending() == 0) {Thread.sleep(1000);}
}
private byte[] retrieveChallengeData(Sasl sasl)
{
byte[] saslChallengeBytes = new byte[sasl.pending()];
sasl.recv(saslChallengeBytes, 0, sasl.pending());
return saslChallengeBytes;
}
was (Author: timtay):
Actually, after doing some digging, I suspect that I don't need to submit a PR
to achieve this functionality. If I understand the Sasl APIs correctly,
I should be able to use the combination of send(...)/recv(...)/pending() to
manually send inits, wait for challenges, receive those challenges,
and send my custom responses to meet the challenges. I can't seem to make it
work, however.
I can successfully send the init frame and am given a challenge frame in
response. I can read that challenge frame just fine and can expose
it to my application just fine. However, when I try to send a response to that
first challenge, the frame I am trying to send is never written.
It is saved as the challenge response, but it is never processed beyond that.
Is the below code expected to work?
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("");
//send init message, wait for response
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive first challenge, send first challenge response, wait for second
challenge
byte[] firstChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive second challenge, send second challenge response
byte[] secondChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
...
private void waitForSaslBuffer(Sasl sasl)
{
while (sasl.pending() == 0)
{
Thread.sleep(1000);
}
}
private byte[] retrieveChallengeData(Sasl sasl)
{
byte[] saslChallengeBytes = new byte[sasl.pending()];
sasl.recv(saslChallengeBytes, 0, sasl.pending());
return saslChallengeBytes;
}
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301860#comment-16301860
]
Tim Taylor edited comment on PROTON-1718 at 12/22/17 7:32 PM:
--
Actually, after doing some digging, I suspect that I don't need to submit a PR
to achieve this functionality. If I understand the Sasl APIs correctly,
I should be able to use the combination of send(...)/recv(...)/pending() to
manually send inits, wait for challenges, receive those challenges,
and send my custom responses to meet the challenges. I can't seem to make it
work, however.
I can successfully send the init frame and am given a challenge frame in
response. I can read that challenge frame just fine and can expose
it to my application just fine. However, when I try to send a response to that
first challenge, the frame I am trying to send is never written.
It is saved as the challenge response, but it is never processed beyond that.
Is the below code expected to work?
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("");
//send init message, wait for response
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive first challenge, send first challenge response, wait for second
challenge
byte[] firstChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive second challenge, send second challenge response
byte[] secondChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
...
private void waitForSaslBuffer(Sasl sasl)
{
while (sasl.pending() == 0)
{
Thread.sleep(1000);
}
}
private byte[] retrieveChallengeData(Sasl sasl)
{
byte[] saslChallengeBytes = new byte[sasl.pending()];
sasl.recv(saslChallengeBytes, 0, sasl.pending());
return saslChallengeBytes;
}
was (Author: timtay):
Actually, after doing some digging, I suspect that I don't need to submit a PR
to achieve this functionality. If I understand the Sasl APIs correctly,
I should be able to use the combination of send(...)/recv(...)/pending() to
manually send inits, wait for challenges, receive those challenges,
and send my custom responses to meet the challenges. I can't seem to make it
work, however.
I can successfully send the init frame and am given a challenge frame in
response. I can read that challenge frame just fine and can expose
it to my application just fine. However, when I try to send a response to that
first challenge, the frame I am trying to send is never written.
It is saved as the challenge response, but it is never processed beyond that.
Is the below code expected to work?
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("");
//send init message, wait for response
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive first challenge, send first challenge response, wait for second
challenge
byte[] firstChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive second challenge, send second challenge response
byte[] secondChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
...
private void waitForSaslBuffer(Sasl sasl)
{
private void waitForSaslBuffer(Sasl sasl)
{
while (sasl.pending() == 0)
{
Thread.sleep(1000);
}
}
private byte[] retrieveChallengeData(Sasl sasl)
{
byte[] saslChallengeBytes = new byte[sasl.pending()];
sasl.recv(saslChallengeBytes, 0, sasl.pending());
return saslChallengeBytes;
}
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301860#comment-16301860
]
Tim Taylor edited comment on PROTON-1718 at 12/22/17 7:31 PM:
--
Actually, after doing some digging, I suspect that I don't need to submit a PR
to achieve this functionality. If I understand the Sasl APIs correctly,
I should be able to use the combination of send(...)/recv(...)/pending() to
manually send inits, wait for challenges, receive those challenges,
and send my custom responses to meet the challenges. I can't seem to make it
work, however.
I can successfully send the init frame and am given a challenge frame in
response. I can read that challenge frame just fine and can expose
it to my application just fine. However, when I try to send a response to that
first challenge, the frame I am trying to send is never written.
It is saved as the challenge response, but it is never processed beyond that.
Is the below code expected to work?
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("");
//send init message, wait for response
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive first challenge, send first challenge response, wait for second
challenge
byte[] firstChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive second challenge, send second challenge response
byte[] secondChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
...
private void waitForSaslBuffer(Sasl sasl)
{
private void waitForSaslBuffer(Sasl sasl)
{
while (sasl.pending() == 0)
{
Thread.sleep(1000);
}
}
private byte[] retrieveChallengeData(Sasl sasl)
{
byte[] saslChallengeBytes = new byte[sasl.pending()];
sasl.recv(saslChallengeBytes, 0, sasl.pending());
return saslChallengeBytes;
}
was (Author: timtay):
Actually, after doing some digging, I suspect that I don't need to submit a PR
to achieve this functionality. If I understand the Sasl APIs correctly,
I should be able to use the combination of send(...)/recv(...)/pending() to
manually send inits, wait for challenges, receive those challenges,
and send my custom responses to meet the challenges. I can't seem to make it
work, however.
I can successfully send the init frame and am given a challenge frame in
response. I can read that challenge frame just fine and can expose
it to my application just fine. However, when I try to send a response to that
first challenge, the frame I am trying to send is never written.
It is saved as the challenge response, but it is never processed beyond that.
Is the below code expected to work?
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("");
//send init message, wait for response
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive first challenge, send first challenge response, wait for second
challenge
byte[] firstChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive second challenge, send second challenge response
byte[] secondChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
...
private void waitForSaslBuffer(Sasl sasl)
{
while (sasl.pending() == 0)
{
Thread.sleep(1000);
}
}
private byte[] retrieveChallengeData(Sasl sasl)
{
byte[] saslChallengeBytes = new byte[sasl.pending()];
sasl.recv(saslChallengeBytes, 0, sasl.pending());
return saslChallengeBytes;
}
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301860#comment-16301860
]
Tim Taylor commented on PROTON-1718:
Actually, after doing some digging, I suspect that I don't need to submit a PR
to achieve this functionality. If I understand the Sasl APIs correctly,
I should be able to use the combination of send(...)/recv(...)/pending() to
manually send inits, wait for challenges, receive those challenges,
and send my custom responses to meet the challenges. I can't seem to make it
work, however.
I can successfully send the init frame and am given a challenge frame in
response. I can read that challenge frame just fine and can expose
it to my application just fine. However, when I try to send a response to that
first challenge, the frame I am trying to send is never written.
It is saved as the challenge response, but it is never processed beyond that.
Is the below code expected to work?
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("");
//send init message, wait for response
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive first challenge, send first challenge response, wait for second
challenge
byte[] firstChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
waitForSaslBuffer(sasl);
//receive second challenge, send second challenge response
byte[] secondChallengeBytes = retrieveChallengeData(sasl);
sasl.send(, 0, );
...
private void waitForSaslBuffer(Sasl sasl)
{
while (sasl.pending() == 0)
{
Thread.sleep(1000);
}
}
private byte[] retrieveChallengeData(Sasl sasl)
{
byte[] saslChallengeBytes = new byte[sasl.pending()];
sasl.recv(saslChallengeBytes, 0, sasl.pending());
return saslChallengeBytes;
}
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Taylor updated PROTON-1718:
---
Comment: was deleted
(was: Let's simplify this a bit to get the ball rolling (When you get back from
break)
Suppose I'm taking the library as it is right now. If I needed to include a
payload in the sasl init frame, is that possible?)
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Taylor updated PROTON-1718:
---
Comment: was deleted
(was: Yes, my issue is more to do with how the Reactor does not allow users
enough control over the Sasl operations in the ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.)
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297571#comment-16297571
]
Tim Taylor commented on PROTON-1718:
Let's simplify this a bit to get the ball rolling (When you get back from break)
Suppose I'm taking the library as it is right now. If I needed to include a
payload in the sasl init frame, is that possible?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297527#comment-16297527
]
Tim Taylor edited comment on PROTON-1718 at 12/19/17 10:27 PM:
---
Yes, my issue is more to do with how the Reactor does not allow users enough
control over the Sasl operations in the ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
was (Author: timtay):
Yes, my issue is more to do with how the Reactor does not allow users to alter
the Sasl operations in the ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297527#comment-16297527
]
Tim Taylor edited comment on PROTON-1718 at 12/19/17 10:20 PM:
---
Yes, my issue is more to do with how the Reactor does not allow users to alter
the Sasl operations in the ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
was (Author: timtay):
Yes, my issue is more to do with how the Reactor does not allow users to alter
the Sasl operations in a ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297527#comment-16297527
]
Tim Taylor commented on PROTON-1718:
Yes, my issue is more to do with how the Reactor does not allow users to alter
the Sasl operations in a ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297167#comment-16297167
]
Tim Taylor edited comment on PROTON-1718 at 12/19/17 6:11 PM:
--
Thanks for the response!
Okay, if this kind of change is unacceptable, maybe you can help me find a
different way to resolve a problem I'm facing. Essentially, the service I need
to do Sasl auth against only allows a custom Sasl mechanism. The flow works as
follows:
1) Service advertises this custom Sasl mechanism as the only option
2) Client sends init message with a payload containing application code data to
the service (sending multiple init messages if the payload is too large for one
frame)
3) Service responds with a challenge asking to send some specific data
4) Client writes a frame with that data in Sasl Response
5) Service responds with another challenge, this time with a payload that
+needs+ to be exposed to our application code for processing.
6) Client sends some challenge response using the processed data from the
previous challenge.
7) Sasl authentication has succeeded
There doesn't seem to be a way for me to implement this custom sasl flow using
the current proton-j library. I can't choose what payload to include in the
init, I can't expose the sasl challenge data exposed to my application for
processing, and I can't tell the library how to handle each iteration of the
challenge-response flow. Am I just missing how to implement a custom sasl
mechanism, or is this a limitation of proton-j?
Of the two commits made in the pull request for this fix, only the first is
necessary for me to implement this. The second commit is simply to allow me to
subclass SaslImpl so that I don't need to re-write and maintain all the logic
that isn't tied to Init/Challenge/Response. Is it possible for this PR to be
approved if I limit it to just the first commit?
was (Author: timtay):
Thanks for the response!
Okay, if this kind of change is unacceptable, maybe you can help me find a
different way to resolve a problem I'm facing. Essentially, the service I need
to do Sasl auth against only allows a custom Sasl mechanism. The flow works as
follows:
1) Service advertises this custom Sasl mechanism as the only option
2) Client sends init message with a payload containing application code data to
the service (sending multiple init messages if the payload is too large for one
frame)
3) Service responds with a challenge asking to send some specific data
4) Client writes a frame with that data in Sasl Response
5) Service responds with another challenge, this time with a payload that
+needs+ to be exposed to our application code for processing.
6) Client sends some challenge response using the processed data from the
previous challenge.
7) Sasl authentication has succeeded
There doesn't seem to be a way for me to implement this custom sasl flow using
the current proton-j library. I can't expose the sasl challenge data exposed to
my application for processing, and I can't tell the library how to handle each
iteration of the challenge-response flow. Am I just missing how to implement a
custom sasl mechanism, or is this a limitation of proton-j?
Of the two commits made in the pull request for this fix, only the first is
necessary for me to implement this. The second commit is simply to allow me to
subclass SaslImpl so that I don't need to re-write and maintain all the logic
that isn't tied to Init/Challenge/Response. Is it possible for this PR to be
approved if I limit it to just the first commit?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297167#comment-16297167
]
Tim Taylor commented on PROTON-1718:
Thanks for the response!
Okay, if this kind of change is unacceptable, maybe you can help me find a
different way to resolve a problem I'm facing. Essentially, the service I need
to do Sasl auth against only allows a custom Sasl mechanism. The flow works as
follows:
1) Service advertises this custom Sasl mechanism as the only option
2) Client sends init message with a payload containing application code data to
the service (sending multiple init messages if the payload is too large for one
frame)
3) Service responds with a challenge asking to send some specific data
4) Client writes a frame with that data in Sasl Response
5) Service responds with another challenge, this time with a payload that
+needs+ to be exposed to our application code for processing.
6) Client sends some challenge response using the processed data from the
previous challenge.
7) Sasl authentication has succeeded
There doesn't seem to be a way for me to implement this custom sasl flow using
the current proton-j library. I can't expose the sasl challenge data exposed to
my application for processing, and I can't tell the library how to handle each
iteration of the challenge-response flow. Am I just missing how to implement a
custom sasl mechanism, or is this a limitation of proton-j?
Of the two commits made in the pull request for this fix, only the first is
necessary for me to implement this. The second commit is simply to allow me to
subclass SaslImpl so that I don't need to re-write and maintain all the logic
that isn't tied to Init/Challenge/Response. Is it possible for this PR to be
approved if I limit it to just the first commit?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16289730#comment-16289730
]
Tim Taylor commented on PROTON-1718:
https://github.com/apache/qpid-proton-j/pull/13
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Taylor updated PROTON-1718:
---
Description:
I would like to be able to provide a custom SASL implementation for Proton-j to
use instead of being forced to use the default SaslImpl.java implementation.
Ideally, code like below would be possible
private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
{
...
}
...
...
//transport.sasl(...) saves the provided sasl implementation and uses it
internally
Sasl sasl = transport.sasl(new CustomSasl());
Do you currently have a workaround that would allow me to use Proton-J this way?
was:
I would like to be able to provide a custom SASL implementation for Proton-j to
use instead of being forced to use the default SaslImpl.java implementation.
Ideally, code like below would be possible
private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
{
...
}
...
...
//transport.sasl(...) saves the provided sasl implementation and uses it
instead of using the default SaslImpl implementation
Sasl sasl = transport.sasl(new CustomSasl());
Do you currently have a workaround that would allow me to use Proton-J this way?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1718) (Proton-J) Custom Sasl
Tim Taylor created PROTON-1718:
--
Summary: (Proton-J) Custom Sasl
Key: PROTON-1718
URL: https://issues.apache.org/jira/browse/PROTON-1718
Project: Qpid Proton
Issue Type: Improvement
Components: proton-j
Affects Versions: proton-j-0.24.0
Reporter: Tim Taylor
I would like to be able to provide a custom SASL implementation for Proton-j to
use instead of being forced to use the default SaslImpl.java implementation.
Ideally, code like below would be possible
private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
{
...
}
...
...
//transport.sasl(...) saves the provided sasl implementation and uses it
instead of using the default SaslImpl implementation
Sasl sasl = transport.sasl(new CustomSasl());
Do you currently have a workaround that would allow me to use Proton-J this way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1606) add option to disable the SASL layer when using the Reactor
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197642#comment-16197642
]
Tim Taylor commented on PROTON-1606:
Do you have an ETA on when the next Maven package release will occur?
> add option to disable the SASL layer when using the Reactor
> ---
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: Tim Taylor
>Assignee: Robbie Gemmell
> Fix For: proton-j-0.23.0
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
> The service I am hitting against is not using Proton-j as the SERVER role.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1606) add option to disable the SASL layer when using the Reactor
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194834#comment-16194834
]
Tim Taylor commented on PROTON-1606:
Thanks for the fast turnaround on this!
> add option to disable the SASL layer when using the Reactor
> ---
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: Tim Taylor
>Assignee: Robbie Gemmell
> Fix For: proton-j-0.23.0
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
> The service I am hitting against is not using Proton-j as the SERVER role.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1606) (Proton-J) Using Sasl needs to be optional for Client Role
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191778#comment-16191778
]
Tim Taylor commented on PROTON-1606:
Yes, I will need a way to disable Sasl for a client.
> (Proton-J) Using Sasl needs to be optional for Client Role
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: Tim Taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
> The service I am hitting against is not using Proton-j as the SERVER role.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1606) (Proton-J) Using Sasl needs to be optional for Client Role
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191713#comment-16191713
]
tim taylor commented on PROTON-1606:
In my scenario, there is no username/password to use. I am trying to use x509
authentication over TLS. The service probably should offer EXTERNAL as a
mechanism to defer to TLS for auth, but it doesn't, so I have to work with that.
The server only expects Sasl communication if I am using username/password. In
my scenario right now, I am not, so it is not expecting any Sasl communication.
> (Proton-J) Using Sasl needs to be optional for Client Role
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
> The service I am hitting against is not using Proton-j as the SERVER role.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1606) (Proton-J) Using Sasl needs to be optional for Client Role
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191586#comment-16191586
]
tim taylor commented on PROTON-1606:
In my scenario, the service I am hitting against is not offering EXTERNAL,
ANONYMOUS, or NONE as viable mechanisms on the client side to avoid using
PLAIN. It only accepts PLAIN, or no SASL communication.
The only way I could get the service to accept communication from my client
using Proton-j was to modify the library such that the global handler does not
create any SASL layer by default.
> (Proton-J) Using Sasl needs to be optional for Client Role
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
> The service I am hitting against is not using Proton-j as the SERVER role.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional for Client Role
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging as
a CLIENT against our service.
...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
The service I am hitting against is not using Proton-j as the SERVER role.
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging as
a CLIENT against our service (SERVER).
...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional for Client Role
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
> The service I am hitting against is not using Proton-j as the SERVER role.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional for Client Role
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Summary: (Proton-J) Using Sasl needs to be optional for Client Role (was:
(Proton-J) Using Sasl needs to be optional)
> (Proton-J) Using Sasl needs to be optional for Client Role
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service (SERVER).
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging as
a CLIENT against our service (SERVER).
...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service (SERVER).
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
\n
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
\n
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
\n
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
\n
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> \n
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> \n
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event) {
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> ...
> Sasl sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
>
> ...
> Sasl sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
tim taylor created PROTON-1606:
--
Summary: (Proton-J) Using Sasl needs to be optional
Key: PROTON-1606
URL: https://issues.apache.org/jira/browse/PROTON-1606
Project: Qpid Proton
Issue Type: Improvement
Components: proton-j
Affects Versions: proton-j-0.22.0
Environment: N/A
Reporter: tim taylor
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event) {
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
