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

Private lists #26

Open
zerok opened this issue Feb 14, 2018 · 0 comments
Open

Private lists #26

zerok opened this issue Feb 14, 2018 · 0 comments

Comments

@zerok
Copy link

zerok commented Feb 14, 2018

The source code already contains the first steps of allowing users to create private lists of sites. After talking with Max Maass about it it seems like the following approach would allow for having not easily-discoverable private lists without the need an account system:

  • The ScanList model would have to be extended with a token field that usually contains a UUID or any other long, random string. This token should be set on creation time.
  • The view_scan_list view would require that token instead of the id/pk field for private lists.

This way, private lists would no longer be reachable through the pk and thanks to that simple brute-forcing IDs to get access to all private lists should no longer be feasible.

Token rotation

As a bit of add-on another token could be stored with each private list that is mailed to the person who created that list. Access to that token would allow someone to change the list and re-generate the token.

Avoiding list-replacements

While UUIDs are rather stable, the system would have to keep track of all the UUIDs who have been used in order to avoid one list accidentally taking the place of a previously deleted list.

Would this make sense to you?

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

1 participant