-
Notifications
You must be signed in to change notification settings - Fork 103
API for deleting accounts #67
Comments
Thanks @akuckartz ! |
As mentioned by @csarven on solid-spec/68 - API to download/export account data: The Export Account functionality should be brought to the user's attention when they start the process to delete their account. Emphasize on the point that "once you delete your account, you will lose this and this and this.. and will never get it back. We don't have archives..." |
Thanks @akuckartz. I had this conversation several times, I will write down notes and questions I took:
|
@nicola - I'm not sure I understand the distinction. Doing an HTTP DELETE to a profile ( The confirmation dialog (or via email) is unrelated to this question, and is just handled via the UI of whatever app is displaying the 'Delete Account' link. So, for example, if you're talking about the Profile Editor app, the 'Delete Account' button would first display a confirmation dialog or page (explaining that the account will be un-reachable from that point on, linking to the Export button, and so on). And only after the user clicks 'Confirm' would the app actually send that HTTP DELETE call. Does that make sense? (The distinction between what the API should be versus what sort of confirmations and explanation the UI should handle?) |
These are old notes, but let me answer your questions:
Let me know if you have further questions! |
Ah, ok, I see what you're saying. In that case, yeah, I agree, it should be done via a non-LDP API endpoint. Something like As for the UI-only confirmation being too soft for the drastic effect, I think I understand. How about -- issuing a A one-time token would be generated, and sent in an email. Something like:
Visiting that page from the email would show confirmation text and explanation of the effects, link to the Export button, and finally display a Confirm Delete button. Which, when pressed, would issue a And so, the 2-factor auth part would be handled via email. Would that work? |
If we are talking about a non-LDP endpoint, yes. If we are talking about an LDP endpoint (which is what I would like to have if we overcome this problem), then I don't think so, since once you DELETE, the content is expected to return a 404 on GET. Maybe @deiu has more insights on this. |
To expand on the non-LDP endpoint 2-factor via email deletion process (I hit submit on that previous comment too soon): How about -- issuing a A one-time token would be generated, and sent in an email. Something like:
Visiting that page from the email would show confirmation text and explanation of the effects, link to the Export button, and finally display a Confirm Delete button. Which, when pressed, would issue a And so, the 2-factor auth part would be handled via email. Would that work? |
You're essentially talking about special-case handling of certain LDP endpoints. By either attaching some post-commit-hook like functionality to those endpoints, or having a Solid server keep a list of "magic" LDP endpoints, and handling them differently (such as only deleting them via a 2-factor auth step). Right? |
Yes (if we agree that the set of APIs of the user are handled in a non-LDP way - which I would like to avoid, otherwise we are just proving that we still need non-LDP apis.. - maybe using capabilities in a very similar way you are proposing) However, if we proceed with non-LDP APIs, we can't force this exact implementation in the spec. It is up to the implementor to choose this way with tokens or other valid alternatives. |
While we can't force exact implementation in the spec (although - why not? The Solid spec is still in progress, even if the LDP spec is finished), we can certainly give recommendations. Isn't that what the Solid project is about? Recommendations to server implementors regarding API endpoints etc? |
@dmitrizagidulin that could be either done with a sort of The token mechanism, for example could be implemented with a finer grain ACL. |
@nicola - tell me more about post commit hook? (is there links?) As for specifying in an ACL file - that sounds promising. What would that look like? |
I see Solid not as a set of "recommendations" but as a set of
|
As mentioned in our off-line gitter chat, I agree with you, in terms of being careful not to over-specify the API. In this issue, we're mostly talking about "how should we implement this initially in Gold and LDNode". :) |
Moving to solid/solid#14 as a result of the solid project workflow discussion. Closing. |
Implement an API for deleting accounts/WebIDs.
solid-spec
gold
- see API for deleting accounts linkeddata/gold#28ldnode
- see Implement API for deleting accounts nodeSolidServer/node-solid-server#177The text was updated successfully, but these errors were encountered: