REST API shows different stream assignments then WebUI

1. Describe your incident:
we are running Graylog 4.3.15. While migrating from V3, we ran into problems. We
could fix all that and meanwhile V4.3.15 is running well. During the fixes, we
had to reset the mongodb and now some of our users have steams shared, that do
not exist any more. Normally you would revoke a shared stream by going to the
stream, clicking on share, and then deleting the user from the steam. But as
the streams do not exist any more, i can’t proceede that way.
That’s why i had a look at the API and found the endpoint
‘/users/{username}/permissions’ where actions ‘put’ and ‘delete’ are defined. My
plan is now to get a user with endpoint /users/{username}. The returned dict
contains a key ‘permissions’ containing a list of permissions. I am analysing
this list. The missing streams are dropped from the list and everything else is
kept. As a result i have a list of permissions, containing only streams, that
are existing. Now i am deleting the user permissions with endpoint
‘/users/{username}/permissions’ and then writing my cleaned permissionslist with
put to the same endpoint.
After doing so, i get a good looking list of permissions when i do a get on
endpoint /users/{username}. But unfortunately, when i look for that user on the
webUI, then the streams in section Shared Entities have not changed at all.
It seems i did not understand the data structure. Aren’t those shared entities
the same as the stream permissions within the user datastructure? How can i
synchronize the two? Or better: How can i achieve, that the assigned streams in
the ‘permissions’ Key are shown in the webui shared entities section also?

2. Describe your environment:

  • OS Information: Centos7

  • Package Version: Graylog 4.3.15

  • Service logs, configurations, and environment variables:

3. What steps have you already taken to try and solve the problem?
I tried to find doctumentation on how to set and revoke stream assignments via Rest API with no success.

4. How can the community help?
Tell me, how to make the stream assignments in the permissions list appear in the webUI. Or even better: Show me, where this is documented.

It looks like the api for shared entities is via /authz/shares

permissions are unrelated to shared content. Hope this helps.

Hi Miranda,
thank you very much for your answer.

Thats right, you can GET the shared streams on a per user basis. The POST method
on the other hand puts users into a shared stream. That’s more or less the other
way around. As described above, the streams are not existing any more. Are you
shure, that i can remove a user from a non existing shared entity with a POST
request to endpoint /authz/shares/entities? This is, what the non existing
stream entity looks like in the output of the GET request:

  "id": "grn::::stream:5420224617f0398625dd3943",
  "title": "ERROR: Stream for <grn::::stream:5420224617f0398625dd3943> not found!",
  "owners": [],
  "type": "stream"

I’m not sure. But if you do get an error you would need to correct the entires in mongo itself.

Ya, reading through this i really wonder if you are at the point where you need to dive into mongodb to fix all this.
If you are at that point I personally would start to wonder what else is wrong that I don’t know, the move from 3 to 4 was pretty big in some ways.

Hi Miranda,
i played around with endpoint /authz/shares/entities/ and came to unexpected
insights. First i created a testuser and then i posted this new user into one of
our steams. Thought, that would add the testuser to the stream or in other
words: share the stream with the testuser. What it did was not an add, but a
replace. I ended up with the stream shared only with the testuser. That has been
unexpected. I had to spend hours to reshare the stream to hundreds of users.

On the other hand, this enabled me to get rid of the broken assignments. I
shared the errorous streams to my testuser, which removes the non existent
streams from all the other users. Then i deleted the testuser and now the system
seems to be clean. No non existent stream in the displayed users any more.

What worked with non existing streams did not work with non existing dashboards.
I tried that with curl like this:

(python3.9) me@mybox:~> curl -u abcabc---------------------------------------:token ‘http://localhost:9000/api/authz/shares/entities/grn::::dashboard:5447bb2817f068fec16bb4fd’ -H ‘Accept: application/json’ -H ‘Content-Type: application/json’ -H ‘X-Requested-By: cli’ --data-raw ‘{“selected_grantee_capabilities”:{“grn::::user:65016261dfb5ce0ed21c2cd8”:“view”}}’

And it gave me:
{“type”:“ApiError”,“message”:“Could not find view with id 5447bb2817f068fec16bb4fd”}

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.