An operator wants to set an expiration data on a whitelist entry because many are for rented
root-servers or virtual-private-servers that run honeypots or crawler which after a while will be shut
down and the IP will be used for something else by the next hirer.
Implementation considerations
If we can get the time of last change and it would be okay to take this time for the use case,
we could use tags with "expire-in-3-month", "expire-6-month" and so on. No extra coding would be required for fody.
Another solution idea is that we use tags that give an explicit expiration date like
"expire-20181011". This has advantage that expiration would be decoupled from the last change
saved in the contact and it would be flexible. For the best usability fody would have to be extended to offer convenience options for expire in 3,6,12 month on a single click. However it would already be testable without fody changes. The rules have to adapted.
cleanup
It seems good to keep the expired manual entries around in the database for audit trail purposes
and if the expiration was wrong. After a while they would need to be cleaned out. This could be added to a regular cleanup process that checks if the expiration data has been more than 12 months or so in the past and then remove the manual entry completely.
wagner-intevation
commented
1 month ago
Use case
An operator wants to set an expiration data on a whitelist entry because many are for rented root-servers or virtual-private-servers that run honeypots or crawler which after a while will be shut down and the IP will be used for something else by the next hirer.
Implementation considerations
If we can get the time of last change and it would be okay to take this time for the use case, we could use tags with "expire-in-3-month", "expire-6-month" and so on. No extra coding would be required for fody.
Another solution idea is that we use tags that give an explicit expiration date like "expire-20181011". This has advantage that expiration would be decoupled from the last change saved in the contact and it would be flexible. For the best usability fody would have to be extended to offer convenience options for expire in 3,6,12 month on a single click. However it would already be testable without fody changes. The rules have to adapted.
cleanup
It seems good to keep the expired manual entries around in the database for audit trail purposes and if the expiration was wrong. After a while they would need to be cleaned out. This could be added to a regular cleanup process that checks if the expiration data has been more than 12 months or so in the past and then remove the manual entry completely.