-
Notifications
You must be signed in to change notification settings - Fork 29
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
Let me get the list of tags or better, add proper metadata, please! #200
Comments
@oderwat users can have tags - not sure if you missed that or you are asking for something else: > nsc add operator O
...
> nsc add account A
...
> nsc add user U
[ OK ] generated and stored user key "UA6Q643B67JEZ6L2L7HXERYPZKGHUNC2VBIMCCNYVPXCYCGPKFWKNWW5"
[ OK ] generated user creds file `/tmp/nsc/nats/nsc/keys/creds/O/A/U.creds`
[ OK ] added user "U" to account "A"
> nsc edit user --tag user=monitor --tag account=demo --tag expires=6-7-22 --expiry 1d
[ OK ] changed jwt expiry to 2023-06-08 13:05:21 UTC - in 23 hours
[ OK ] added tag "user=monitor"
[ OK ] added tag "account=demo"
[ OK ] added tag "expires=6-7-22"
[ OK ] generated user creds file `/tmp/nsc/nats/nsc/keys/creds/O/A/U.creds`
[ OK ] edited user "U"
> nsc describe user U
+---------------------------------------------------------------------------------+
| User |
+----------------------+----------------------------------------------------------+
| Name | U |
| User ID | UA6Q643B67JEZ6L2L7HXERYPZKGHUNC2VBIMCCNYVPXCYCGPKFWKNWW5 |
| Issuer ID | ACMTEM7JTVRTX3AE7MGAUOPG6TNCQBBTWNAXLBKSRMIL6BANDKNJEAEU |
| Issued | 2023-06-07 13:05:21 UTC |
| Expires | 2023-06-08 13:05:21 UTC |
| Tags | account=demo |
| | expires=6-7-22 |
| | user=monitor |
| Bearer Token | No |
| Response Permissions | Not Set |
+----------------------+----------------------------------------------------------+
| Max Msg Payload | Unlimited |
| Max Data | Unlimited |
| Max Subs | Unlimited |
| Network Src | Any |
| Time | Any |
+----------------------+----------------------------------------------------------+
> nsc describe jwt -f /tmp/nsc/nats/nsc/keys/creds/O/A/U.creds
+---------------------------------------------------------------------------------+
| User |
+----------------------+----------------------------------------------------------+
| Name | U |
| User ID | UA6Q643B67JEZ6L2L7HXERYPZKGHUNC2VBIMCCNYVPXCYCGPKFWKNWW5 |
| Issuer ID | ACMTEM7JTVRTX3AE7MGAUOPG6TNCQBBTWNAXLBKSRMIL6BANDKNJEAEU |
| Issued | 2023-06-07 13:05:21 UTC |
| Expires | 2023-06-08 13:05:21 UTC |
| Tags | account=demo |
| | expires=6-7-22 |
| | user=monitor |
| Bearer Token | No |
| Response Permissions | Not Set |
+----------------------+----------------------------------------------------------+
| Max Msg Payload | Unlimited |
| Max Data | Unlimited |
| Max Subs | Unlimited |
| Network Src | Any |
| Time | Any |
+----------------------+----------------------------------------------------------+ |
The restrictions on lower-case are to simplify matching and other sorts of things - we have seen use tags quite frequently (and we ourselves use them - nats-server uses them internally I believe). We usually specify key/value relationships as I have shown above. We could restrict the lower-case requirements, but the format is likely not going to change because as I said above many folks use the current tag mechanism fairly extensively |
I want the list of the tags and not just "Contains('some_tag')". I know that they can have tags. So if you use 'account=demo' which would be 'account:demo' for me, but that is a minor detail in the implementation. How do you access them using the JWT package? It does not expose them, that is what I was asking about. For now, we use:
|
We want to store "meta" style information in the creds file. This would be easy by using a tag with a prefix. We would want to use if, for example to add a
account_PRODUCT-BETA
because showing the issuer account public key, does not help much if you don't have a list of all of them that translate the name to a "user readable" name. I saw #101 which seems to have a similar purpose. As is, we need to check with "Contains" for all possible values. There are quite a lot of use case where it would be nice to be able to store information in the creds like the email of the user or some IDs from other systems. It would also be nice because you could show the tags of the claims with "the" standard package for handling these JWTs.EDIT: We parse it now from the JWT string, while doing that it struck me that the tags are also forced to be lower case. I do not really understand what all of these restrictions are about. I would suggest adding a proper way to add string indexed string metadata to the user JWT.
The text was updated successfully, but these errors were encountered: