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

Get words, if multiple api-keys are used #428

Closed
ztefanie opened this issue Jan 31, 2023 · 3 comments
Closed

Get words, if multiple api-keys are used #428

ztefanie opened this issue Jan 31, 2023 · 3 comments

Comments

@ztefanie
Copy link
Member

Motivation

We want to show a user all vocabulary, she has access to. E.g. lunes-standard and protected by api-key1 and protected by api-key2.
Currently there is only the option to:

  1. call /api/words endpoint, getting all lunes standart vocabulary
  2. call api/words with ONE api-key, getting all lunes standard vocabulary plus the vocabulary of ONE custom disicpline.

But if a user has two api-keys we would have to filter a lot of duplicates and as there is a lot of data, i think it is to slow. 

Proposed Solution

Make it possible to add more than one api-key to the request (I guess this is not possible as the api-keys are send with the Auth-Header).

Alternatives

Only send custom words if api/words is called with api-key.

Additional Context

Users have a dictionary where they can search in all words.
Releated to: #405
App-issue: https://issues.tuerantuer.org/browse/LUN-434

@timobrembeck
Copy link
Member

How urgent is this? This would be implicitly solved by API version 2 (#376).
I also suggested to think of the keys more as filters for the API than an actual secrets and to pass them as GET-parameters instead of the auth header for the next API version, which would also make it easy to pass multiple keys.

@ztefanie
Copy link
Member Author

Not really urgent, as long as we do not have it, only lunes standard vocabulary is show in the dictionary, but I think this is fine, as there is almost no really actively used custom discipline right now.
Moving keys to the get-parameters sounds reasonable.

@timobrembeck
Copy link
Member

Ok, then I'm going to close this in favor of #376.

@timobrembeck timobrembeck closed this as not planned Won't fix, can't repro, duplicate, stale Jan 31, 2023
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