wildcards should have permissions with user

[welldonexing]

Proposed change

now nats have * . > wildcards can take the place of one or more elements in a dot-separated subject. but when we use like
" order.userid.send " we just want user to subscribe his id's message, but users can use order.*.send or even order.>.send
to subscribe all the users message. In the authorization ,we could not ban the wildcards ,if can ban the wildcards,its safe to have a long id,and protect the msg from others to see. we know that all the user use the same username,because it couldnt be modifiy when it was running(such as add user). and the good way is to ban the wildcards to user that's easy to do.

Use case

ban the wildcards to any user

Contribution

No response

[derekcollison]

If you use an explicit allow block for the subs, they will be the only ones allowed.

[welldonexing]

If you use an explicit allow block for the subs, they will be the only ones allowed.

Thank you for your reply , as i know the config allow block can not change when running, as my user almost unlimit , it 's difficult to add allow block to every user, my webside will auto create a userid when connecting like "order.0CFFFF3ADGAR.send",
now is working , so the only one ploblem is user can "order.*.send" subscribe all the id. A different way to solve this problem is reply request ,and ban all the subscribe.But this way i haven try. But juse ban The wildcards for the user may be the faster way to this. the config maybe

authorization: {
users: [
{ user: a, password: a },
{ user: b, password: b, permissions: {subscribe: "q", allow_wildcards : false } },

]

}

[derekcollison]

Yes if the subjects are very dynamic wildcards help express the scope. In these case I can see a desire to restrict to literal subjects.

[ripienaar]

Only real way we have today is to put your user in a different account and import let’s say orders.tenantid.> into the tenant account as orders.>

Accounts offer a much more usable way of achieving this really

[welldonexing]

Only real way we have today is to put your user in a different account and import let’s say orders.tenantid.> into the tenant account as orders.>

Accounts offer a much more usable way of achieving this really

yes i have think of this for some times if i use orders.tenantid.> like order.0CFFFF3ADGAR.> to sub in my server,
user still can use order.*.> to get all the answer, We know that if user wants to get data ,It muse be allowed to subscribe.
What ever i do ,It may have some ways to get others data.or severs data. But for common use ,is enouth.Now my project Is working.my webside will auto create a userid when connecting like "order.0CFFFF3ADGAR.send",Its hard to add userid in config when connecting

[ripienaar]

Accounts let your user not even think about it or know their ID and the wildcard subscribe will do the right thing.