Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authorization on _INBOX.> #192

Closed
ramasa opened this issue Nov 12, 2018 · 2 comments
Closed

Authorization on _INBOX.> #192

ramasa opened this issue Nov 12, 2018 · 2 comments

Comments

@ramasa
Copy link

ramasa commented Nov 12, 2018

We are using nats as a channel for JSON-RPC and exposed it to our client so that they can invoke our API using Message reply = nc.request("req.foo", request)
How do I prevent our client from subscribing to '_INBOX.>' and read other's response?

authorization {
CLIENT = {
publish = ["req.foo", "req.bar"]
subscribe = "_INBOX.>"
}

Only way I see now is to mimic NatsConnection.request method to use a custom inbox like _INBOX.clientid.*

and set client specific rule as below
authorization {
CLIENT1 = {
publish = ["req.foo", "req.bar"]
subscribe = "_INBOX.client1.>"
}

Exposing NatsConnection.INBOX_PREFIX might help?

@sasbury
Copy link
Contributor

sasbury commented Nov 20, 2018

I am going to look at making that public, but had a thought about making it an option, not sure what the effect would be in the client, I will have to double check. What do you think about having that be settable?

@ramasa
Copy link
Author

ramasa commented Nov 21, 2018

Not much familiar with client implementation but as a user below options comes to mind

  1. io.nats.client.Options parameter
  2. io.nats.client.Connection.request parameter
  3. or generic way - by default use _INBOX.<username>. as prefix , where <username> is the authorized user?

One more clarification, Our customer use .NET client, should I raise this issue in nats-io/csharp-nats project also?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants