1072184 - Handle DELETE /account, /session and /registration

Status: RESOLVED FIXED

(Hello (Loop) :: Server, defect)

Description

[Alexis Metaireau (:alexis)]

Make sure there is more than one hawk session associated with the user.

If not answer with 403 Forbidden.

We can also return the method to use instead: DELETE /account.

Comment 1

[Rémy Hubscher (:natim)]

Attachment: Link to Github PR — #220.

Now that SimplePushURLs are linked directly to the Hawk Session, it makes sense to remove both on DELETE /registration

Comment 2

[Alexis Metaireau (:alexis)]

Adding a note here while doing the triage: It's possible this is not doing the right thing here: it's deleting the hawkid of anonymous users (so they don't exist anymore).

Currently, this API allows user to unregister a simple push url, marking them as offline.

Comment 3

[Alexis Metaireau (:alexis)]

Comment on attachment 8500994 [details] [review]
Link to Github PR — #220.

Yep, that's not how we want to do things for now: let's keep it possible to just unregister, which is what the current DELETE on /registration does (which is different from the DELETE /session).

Comment 4

[Rémy Hubscher (:natim)]

Then we should probably remove the mandatory parameter in POST /registration because asking POST /registration with a fake simplePushURL and the asking for DELETE /registration will basically do the same thing.

Comment 5

[Alexis Metaireau (:alexis)]

Nope, that's different: when you register, you need to pass a way to contact you back, and then you can say this is not valid anymore (using delete).

Effectively, that would do the same thing but they're conceptually different: post /registration registers you with a way to get back to you and delete /registration removes the way to contact you (e.g. you're offline).

Comment 6

[Rémy Hubscher (:natim)]

I don't understand why you couldn't connect as an offline participant.
Also in that case we don't handle this correctly because then we should answer the link-clicker that the user is not present.

Are we supposed to handle the presence of a user on the server side?

Mark — Does current client implementation relies on this when going offline?

Comment 7

[Alexis Metaireau (:alexis)]

If that makes sense to register as an offline participant, then we could allow that behavior.

We're not supposed to handle all the presence of the users on the server side, but here that actually makes sense to have it for free, hence why we're doing it like that.

Comment 8

[Rémy Hubscher (:natim)]

Ok so after further discussion here is what we are planning to implement:

 - POST /registration will now have simplePushURLs optional
 - POST /registration with simplePushURLs will override the session simplePushURLs

 - DELETE /registration will remove simplePushURLs for the user putting him as offline without removing it ability to get back online.

 - DELETE /session will remove the connected user session and drop its simplePushUrls
 - DELETE /session on a unconnected user will raise a 403

 - DELETE /account will remove a user and everything that it linked to it (call-urls/sessions)

Basically an unconnected user will have to use DELETE /account instead of DELETE /session because a drop of its session will not let him get its user data.

Comment 9

[Mark Banner (:standard8)]

Seems reasonable, please ensure the documentation gets updated for this. It might also be worth a general section explaining the differences as per comment 8.

Comment 10

[Rémy Hubscher (:natim)]

https://github.com/mozilla-services/loop-server/commit/8b2a8e96b1d6748c0c9503f655d0adcce6709303

Comment 11

[Rémy Hubscher (:natim)]

Documentation updated: https://github.com/mozilla-services/docs/commit/746c8f1b4e516bfac21adfba7c7965869aada627