You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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:
ScanList
model would have to be extended with atoken
field that usually contains a UUID or any other long, random string. This token should be set on creation time.view_scan_list
view would require that token instead of theid
/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?
The text was updated successfully, but these errors were encountered: