Feature/Tenant Token: Add a module which can generate tenant tokens #299
Conversation
This will help to test the generate_tenant_token feature, without this I will need to implement the decode by hand, and test it.
According to the spec meilisearch/specifications#89
brunoocasali
force-pushed
the
feature/tenant-token
branch
from
dc51ece to
65279dd
Compare
|
bors try |
brunoocasali
changed the title
brunoocasali
force-pushed
the
feature/tenant-token
branch
from
4a09ebd to
f8061fc
Compare
| end | ||
|
|
||
| def retrieve_valid_key!(*keys) | ||
| key = keys.compact.find { |k| !k.empty? } |
There was a problem hiding this comment.
Are you checking the given key is an already existing key in the search engine?
the list of the keys is only retrievable if you pass the master key. What if the users want to use generate_tenant_token but don't instanciate the Client with the master key?
There was a problem hiding this comment.
Are you checking the given key is an already existing key in the search engine?
Actually not, thegenerate_tenant_tokenmethod does not make an external request.
What I tried to achieve with this method, is to enable an optional behavior:
If the user wants to generate a token with a particular key, they can: client.generate_tenant_token(rules, api_key: new_key).
Otherwise, we will use the "default" key client.generate_tenant_token(rules), which means, we will use the @api_key defined when the user instantiated the client: client = MeiliSearch::Client.new(url, "masterKey") (we will use the "masterKey") then.
There was a problem hiding this comment.
I'm not sure if we should validate the keys using the client.keys, because like you said, it is possible that the user instantiates the client with a key without the superpowers. And if they do that, we'll have a problem handling it, will not be clear to the user what is the "correct behavior".
And there are other possible situations if we validate the key using the keys from the server:
- We will have to raise an error if the user uses the
masterKeyin the method, when theclientis instantiated with the masterKey, ok, we will know that, but when the client was instantiated with another key we will not be able to know which is themasterKeythe user used to start the server. - And if the core changes which key is allowed to create tokens, suppose that only keys with the action "keys.create" is allowed to do that, we know need to introduce a change in every SDK fixing this behavior the SDK will be tightly coupled with the business rules in the core.
There was a problem hiding this comment.
Sorry we're talking about this earlier and I completely forgot that it was only possible to check the other keys with the master key.
| end | ||
|
|
||
| def retrieve_valid_key!(*keys) | ||
| key = keys.compact.find { |k| !k.empty? } |
There was a problem hiding this comment.
Sorry we're talking about this earlier and I completely forgot that it was only possible to check the other keys with the master key.
|
@alallema I've added a use case to test the UTC thing as you mentioned in the Dart SDK! |
brunoocasali
added
skip-changelog
Create the
generate_tenant_tokenfollowing the specification meilisearch/specifications#89