Changes between Version 2 and Version 3 of RightToErasure
- Timestamp:
- Apr 4, 2018, 2:30:59 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RightToErasure
v2 v3 13 13 - You will receive an email which contains a link. Please click on that link. 14 14 - On the page displayed, you will need to re-enter your password and then click “Delete my Account” 15 - At this point the account is scheduled to be deleted. The actual deletion will occur within 48 hours. 15 16 16 At this point all information about your account will be immediately deleted.”17 At any point before the delete occurs you can return to this page and cancel the scheduled deletion. 17 18 }}} 18 19 Once the user provides their password, an email is sent to the user with a link that is similar to: … … 21 22 <base_url>/confirm_delete_account.php?userid=<userid>&token=<token> 22 23 }}} 23 When they click on the link they will be taken to a page that asks them if they are sure that they want to delete their account. They must re-enter their password and click the button that says "delete account" in order to have there account deleted. The account will be immediately deleted at this point and the user will be redirected to the project's home page.24 When they click on the link they will be taken to a page that asks them if they are sure that they want to delete their account. They must re-enter their password and click the button that says "delete account" in order to have there account deleted. They will be informed that their account has been scheduled to be deleted within the next 48 hours. 24 25 25 26 If the user returns to the request_delete_account.php while they have an active token, the page will ask them to check their email for the email that was sent and then provide them with an option to generate a new email if they cannot find the first one. This will again require the user to enter their password to generate the email. 27 28 If the user returns to the request_delete_account.php while the delete is scheduled they will see a message that states that there account is scheduled to be deleted but that they can cancel the deletion by clicking a button. 26 29 27 30 == Technical Implementation == … … 46 49 * public_cross_project_id varchar(254) not null 47 50 * delete_time not null default unix_timestamp() 51 52 === Altered Tables === 53 user 54 * delete_request_time int nullable 48 55 49 56 === Token Generation === … … 95 102 }}} 96 103 97 We are proposing this is changed to 104 We are proposing this is changed to so that users that remain continue to be exported in users.xml as before. However, users who have been deleted will no longer be exported in this file. 98 105 99 106 {{{ … … 109 116 <teamid>118</teamid> 110 117 </user> 118 }}} 119 However, there will also be a new file created called user_deleted.xml that contains a list of users who have been deleted. 120 {{{ 111 121 <user> 112 122 <id>13384</id> 113 123 <cpid>a09031094836310f043f0ff8bcfca355</cpid> 114 <deleted/>115 124 </user> 116 125 }}} 117 126 118 The deleted tag being used to signify those records that must be deleted from the downstream system. The db_dump utility would first export records from the user table and then export records from the user_deleted table to generate these records.127 The user_deleted file indicates those users that must be deleted from the downstream system. The db_dump utility would first export records from the user table and then export records from the user_deleted table to generate these two files. 119 128 120 The host.xml will be changed similarly so that a record for a host that has been deleted would look like:129 Hosts would be handled similarly where the existing host.xml would only contain those hosts that still exist on the host table and that host_deleted.xml would contain those that were deleted and would look like: 121 130 122 131 {{{ … … 124 133 <id>884</id> 125 134 <host_cpid>36e9d265f8fe553bedbbef1cd21a6182</host_cpid> 126 <deleted/>127 135 </host> 128 136 }}} 129 137 130 This portion of db_dump would pull from host and then from host_deleted to collect the data. 138 This portion of db_dump would pull from host and then from host_deleted to create the files. 139 140 === confirm_delete_account_action.php === 141 On the confirm_delete_account.php page, then token should be included as a hidden field. The confirm_delete_account_action.php page that receives the request should validate both the users password and the users token before processing. Only if both are valid should this occur. If they are both valid, then the user.delete_request_time will be set to unix_timestamp(). 142 131 143 132 144 === delete_account.php === 133 The delete of the account is final and is not recoverable in anyway. On the confirm_delete_account.php page, then token should be included as a hidden field. The delete_account.php page that receives the request should validate both the users password and the users token before allowing the delete to proceed. Only if both are valid should this occur.145 The delete of the account is final and is not recoverable in anyway. The delete_account.php script would be a script that runs once a day that seeks user records that have a value of delete_request_time < unix_timestamp() - 24*3600 and delete_request_time > 0 (in case for some reason a 0 gets inserted instead of null). 134 146 135 The deletewill consist of the following actions:147 For each user identified, the delete_account.php will consist of the following actions: 136 148 * An entry will be inserted into the user_deleted table 137 * An entry will be inserted into the host_deleted table for each host record the user has 149 * An entry will be inserted into the host_deleted table for each host record the user has. 138 150 * All entries for the user will be deleted from the following tables: 139 151 * badge_user
