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

drive invites seem to be spammed for a few people #510

Closed
bobheadxi opened this issue Sep 29, 2020 · 8 comments · Fixed by #540
Closed

drive invites seem to be spammed for a few people #510

bobheadxi opened this issue Sep 29, 2020 · 8 comments · Fixed by #540
Assignees
Labels
needs info Requires more details priority:high For issues with high priority, because of deadlines, security reasons, or sometimes both. theme:bug Something isn't working

Comments

@bobheadxi
Copy link
Member

bobheadxi commented Sep 29, 2020

I have not experienced this myself, and judging from the general lack of complaints this is generally not the case, but there is at least once case: https://ubclaunchpad.slack.com/archives/CK93HTYQN/p1601316108020500

I'm surprised this is happening, because the code excludes existing shares:

https://sourcegraph.com/github.com/ubclaunchpad/rocket2/-/blob/interface/gcp.py#L38-49

We do log the entire permissions object, so we might be able to check the logs to see if there are any without an emailAddress. The email invite might contain the permission ID for easier search across the logs.

@bobheadxi bobheadxi added theme:bug Something isn't working needs info Requires more details labels Sep 29, 2020
@bobheadxi
Copy link
Member Author

bobheadxi commented Sep 29, 2020

I suspect this is caused by #497 which might be deleting existing shares, and might be partially resolved by #504 with 35e1209

However if that were the case, I'd expect a lot more people to complain

@jedyeo
Copy link

jedyeo commented Sep 29, 2020

image

Rocket keeps spamming me with invites every couple of hours, so each time I accept the invitation, I gain permissions for the drive, but the next invite also seems to revoke those privileges.

This only seems to be happening for some users.

Timestamps of the invites:
Sept-27 3:12pm
Sept-27 6:31pm
Sept-27 8:36pm
Sept-28 12:56am
Sept-28 3:17am
Sept-28 8:52am
Sept-28 6:39pm

The invites seem to have stopped for now. Unfortunately I do not see anywhere on the email that contains a permission ID, so what I did was accept the invitation and was able to capture something that resembled a UID at the end of the browser link that appeared very briefly as the drive loaded: 5f729053. Sadly I do not know if this corresponds to anything.

I also have access now so no need to change anything regarding my permissions!

@bobheadxi

@jedyeo
Copy link

jedyeo commented Sep 29, 2020

OK, I just got another invite at 12:07pm today

@ctong25
Copy link

ctong25 commented Sep 29, 2020 via email

@bobheadxi
Copy link
Member Author

bobheadxi commented Sep 30, 2020

Thanks everyone!

@cheukyin699 do you mind checking if there's any permissions entries logs at some of these times where the permissions don't contain an emailAddress? (or DM me with how I can get myself set up with logs access)

update: I now have access to logs and do not see anything out of the ordinary, so I'll ping back here post-#504

@bobheadxi
Copy link
Member Author

Changes from #504 did not seem to alleviate this issue. I'm almost certain it is caused by #497, but do not understand why it's not affecting some people (ie I don't receive duplicate invites)

@bobheadxi bobheadxi added the priority:high For issues with high priority, because of deadlines, security reasons, or sometimes both. label Oct 4, 2020
@bobheadxi
Copy link
Member Author

I'm hearing a lot more cases of this now, so I'm just going to go ahead and disable permissions deletion for now in #540 - #497 will track a longer-term fix

@ctong25
Copy link

ctong25 commented Oct 5, 2020 via email

bobheadxi added a commit that referenced this issue Oct 17, 2020
Drive shares frequently get recreated because we fail to page through all results (we likely have over 100 shares for large folders), and when deletion was enabled (#540) we would also erroneously delete inherited permissions. Both of these issues result in many users receiving duplicate invites whenever Rocket performs a sync (#510, #497). To amend this, we make the following changes:

* Permissions listing is now paginated
* Permissions listing now happens for direct parents of target folders - permissions discovered in parents are treated as "inherited", and for these permissions we skip both recreation and deletion

Co-authored-by: Cheuk Yin Ng <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs info Requires more details priority:high For issues with high priority, because of deadlines, security reasons, or sometimes both. theme:bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants