List users / delete all records?

[floomy]

I understand there is no user management, but...

• Is it possible to list all users (user ids)?
• How to delete all records owned by a particular user?

Thanks!

[almet]

1. Not sure what you mean with "list all users", since we don't have any concept of users.
2. To delete records owned by a particular user, you need to authenticate as this user and issue a DELETE request on the collection.

[Natim]

Is it possible to list all users (user ids)?

If by list all users you mean, list all user ids that have at list one permission on a resource.

We do not have this method to permissions backends yet: https://github.com/mozilla-services/cliquet/blob/master/cliquet/permission/__init__.py

Can you elaborate on what would be the use case for that? It could be added if necessary.

How to delete all records owned by a particular user?

As an administrator? As the user? At which level (server, bucket, collection)?

It is possible to get all the objects for a particular user using https://github.com/mozilla-services/cliquet/blob/master/cliquet/permission/__init__.py#L89

Then it is possible to remove all this objects at once.

Also that's not a public API.

[leplatrem]

Raw Python internals might not be the most convenient way :)

@floomy would you expect something like a shell script to purge, or your need would a priviledged HTTP API to be manipulated from the app?

[floomy]

My reasoning was handling orphaned data (as administrator) e.g. testing records during development or outdated records from since canceled projects.

I'd like to clean up records from abandoned users (without keeping track of every single token). I'm not sure if this could be part of the HTTP API.

[Natim]

handling orphaned data (as administrator) e.g. testing records during development or outdated records from since canceled projects.

For this you can simply delete the bucket related to the project:

DELETE /buckets/abandoned_or_test_project_bucket_id

I'd like to clean up records from abandoned users

How do you detect that a user id has been abandoned?

[floomy]

OK, I will then use multiple buckets (instead of multiple users' default bucket) and delete old "stuff" with the /buckets endpoint.

Thanks for your help!

[Natim]

Actually default bucket is a shortcut to distinct bucket id.
You can get the bucket id of a user by calling the / endpoint (while being authenticated) or the /buckets/default endpoint and looking at the id:

GET /v1/buckets/default HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Authorization: Basic dG9rZW46bXktc2VjcmV0
Connection: keep-alive
Host: kinto.dev.mozaws.net
User-Agent: HTTPie/0.9.2



HTTP/1.1 200 OK
Access-Control-Expose-Headers: Content-Length, Expires, Alert, Retry-After, Last-Modified, ETag, Pragma, Cache-Control, Backoff
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 187
Content-Type: application/json; charset=UTF-8
Date: Thu, 18 Feb 2016 08:02:35 GMT
ETag: "1455782547511"
Last-Modified: Thu, 18 Feb 2016 08:02:27 GMT
Server: nginx

{
    "data": {
        "id": "e777874f-2936-11a1-3269-68a6c1648a92", 
        "last_modified": 1455782547511
    }, 
    "permissions": {
        "write": [
            "basicauth:c635be9375673027e9b2f357a3955a0a46b58aeface61930838b61e946008ab0"
        ]
    }
}

GET /v1/ HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Authorization: Basic dG9rZW46bXktc2VjcmV0
Connection: keep-alive
Host: kinto.dev.mozaws.net
User-Agent: HTTPie/0.9.2



HTTP/1.1 200 OK
Access-Control-Expose-Headers: Retry-After, Content-Length, Alert, Backoff
Connection: keep-alive
Content-Length: 505
Content-Type: application/json; charset=UTF-8
Date: Thu, 18 Feb 2016 08:03:00 GMT
Server: nginx

{
    "capabilities": {}, 
    "cliquet_protocol_version": "2", 
    "http_api_version": "1.3", 
    "project_docs": "https://kinto.readthedocs.org/", 
    "project_name": "kinto", 
    "project_version": "1.11.2", 
    "settings": {
        "attachment.base_url": "https://kinto.dev.mozaws.net/attachments/", 
        "batch_max_requests": 25, 
        "cliquet.batch_max_requests": 25, 
        "readonly": false
    }, 
    "url": "https://kinto.dev.mozaws.net/v1/", 
    "user": {
        "bucket": "e777874f-2936-11a1-3269-68a6c1648a92", 
        "id": "basicauth:c635be9375673027e9b2f357a3955a0a46b58aeface61930838b61e946008ab0"
    }
}

You can notice that the bucket_id for this user is: e777874f-2936-11a1-3269-68a6c1648a92
Note that a user can add permission on this to share it with other users as if it was normal bucket.

An administrator can look at all the existing buckets by calling:

GET /v1/buckets HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Authorization: Basic dG9rZW46bXktc2VjcmV0
Connection: keep-alive
Host: kinto.dev.mozaws.net
User-Agent: HTTPie/0.9.2



HTTP/1.1 200 OK
Access-Control-Expose-Headers: Content-Length, Expires, Alert, Retry-After, Last-Modified, Total-Records, ETag, Pragma, Cache-Control, Backoff, Next-Page
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 86
Content-Type: application/json; charset=UTF-8
Date: Thu, 18 Feb 2016 08:04:53 GMT
ETag: "1455782547511"
Last-Modified: Thu, 18 Feb 2016 08:02:27 GMT
Server: nginx
Total-Records: 1

{
    "data": [
        {
            "id": "e599a995-92b2-2f26-1027-c1168114592e", 
            "last_modified": 1455782879954
        }, 
        {
            "id": "e777874f-2936-11a1-3269-68a6c1648a92", 
            "last_modified": 1455782547511
        }
    ]
}

[glasserc]

I am implementing something similar to this right now. One difficulty I had was defining objects that are "owned" by a user. I guess I can say any object for which the user is the only one to have write permission on it is "owned" by that user.

Probably this endpoint should require that the user authenticate, but often you need an endpoint like this after the user is gone, so that probably means this endpoint needs to be accessible by some "superuser". I think I'd require that a PR adding this endpoint should also add a config option for which principals are allowed to access it, defaulting to none. System administrators can turn the feature on by either providing their own user principal, or for instance by allowing system.Everyone and limiting access to the endpoint using nginx or something.