Fix for ignoring a private inbox prefix in jetstream publish.

[oderwat]

Our application did not work anymore after adding some more security to it. Turned out that jetstream publish is not obeying a custom inbox prefix.

[oderwat]

I hope this can get merged quickly, we need this for production code.

[Jarema]

Thanks for the PR! I will took a look into it shortly.

[Jarema]

Thanks for your PR!

This change does fix ignoring the prefix, however it should use the short token variant (as used for the other part of the reply subject).
Please let me know if you need help with that.

[oderwat]

I have no idea what you are talking about. What short token variant? How is that related to the inbox prefix? Sounds as if there are other concerns about your code. I just replaced the inbox prefix which was also a simple string before.

[Jarema]

Hey,

The issue is that NewInbox does not return just a prefix.

It returns {prefix}.{NUID}.

Let's take an example:

• your custom prefix is CUSTOM.
• NewInbox() returns CUSTOM.XuFQG7A9VC8KKttILvXPUk

Now, as the reply subject sub is created here:

js.publisher.replyPrefix = fmt.Sprintf("%s%s.", js.conn.NewInbox(), b[:aReplyTokensize])

if b[:aReplyTokensize] is 7qVSIW

The resulting inbox sub will be: CUSTOM.XuFQG7A9VC8KKttILvXPUk7qVSIW - {prefix}.{NUID}{short_token} which is much longer than necessary.

while it should be CUSTOM.7qVSIW.

If that is confusing (as those are some internal NATS conventions), If you allowed contributors pushing to your branch, I can fix this one with a second commit. Or you can amend your changes. Whatever you prefer 🙂

[oderwat]

@Jarema Yes, that was an oversight of me. Sorry for not getting it directly. That is fixed, but there are so many ways to code it. I saw other instances using a string builder or an optimal allocation + copy. I kept it at the Sprint()-

[Jarema]

LGTM!

Thanks for your contribution!

[oderwat]

What is the ETA for this bugfix to be included in a release?