cwbooth5
commented
3 years ago Delete operations are already restricted to the logged in users, but there's no barrier to logging in. At this point, the login is only for a paper trail and a person to contact with questions on a link, list, or action performed on those things. That's good, since we can at least use this code to create a proper login workflow complete with AAA.
The first request for locking might manifest itself as a simple permissions model. I'd have to write that from the ground up, unless there's some other AAA solution I can import and leverage. I prefer to write my own stuff just to learn and to see if I can do it.
The second request is pretty easy. We keep a log in memory and write it out to the link database on disk on exit and/or at a time interval. I think it would make sense to have two general bits of data in this log - timestamped records of redirects being used and timestamped CRUD operations on the resources. We'd also want to have a record of things deleted by users so we can understand what we used to have. Think about Netflix. Imagine if they had a little service that published what they're about to delete or what they just deleted. That's useful.
In the light of a recently mentioned problem, we believe that this is an issue. We need to be able to lock redirects out of deletion, akin to locks on wikipedia. In fact, we should have a history of what happened to all the links over time.