Restricting `q=source` based on scopes

[jamietanna]

Within my own Micropub server, I have implemented a restriction on q=source to only allow clients with undelete access to view/list deleted posts.

I wonder how others feel about having this restriction in their own implementations, or if anyone does similar?

[jalcine]

I do this for Koype but I haven’t had a client to try this out on.

(Originally published at: https://v2.jacky.wtf/post/b4a35724-778b-4def-9b60-88b9fafd0fa7)

[jamietanna]

Micropublish should work, I think? Maybe trying to edit a deleted post?

(Originally published at: https://www.jvt.me/mf2/2020/07/hppmx/)

[barryf]

When you log in to Micropublish there are two scope presets for authorisation: post or create update delete undelete. If you choose the first option (intended for backwards compatibility of servers) then you'll only see the create actions. The second option will unlock the editing/delete/undelete controls.

So as things stand I'm not sure Micropublish would help testing this scenario. It wouldn't be too hard to make this a bit more granular, at least for testing.

[jamietanna]

Sorry, I should've added a bit more context on how I would use Micropublish to verify this.

Using the deleted post https://www.jvt.me/mf2/2020/04/dd338/, which returns 400 when performing q=source:

• Log into Micropublish with the undelete scope present
• Edit the deleted post
• See the post's metadata present

(Originally published at: https://www.jvt.me/mf2/2020/07/s65rh/)

[vikanezrimaya]

TIL there's an undelete scope, I think my server used delete for undeletion too.

I might want to build something like this, even though my frontend that uses ?q=source actively checks for dt-deleted on posts and shows a tombstone if a post is deleted. We don't have any rogue clients that could read these posts and leak them somewhere though, do we?...

[barryf]

I like this restricted approach based on scope. I'm currently building a new headless Micropub server for my website with a separate front-end as a client. The website uses the read scope to fetch all content via ?q=source requests.

My new server will restrict results based on the scope and visibility / post-status properties:

• Requesting a list (e.g. ?q=source&post-status=article) will only return public and published articles.
• Requesting a specific post (e.g. ?q=source&url=...) returns any public/unlisted and published/draft posts.

Neither will return a private post on my new website. However, when using a client like Quill/Micropublish with the update, delete or undelete scopes I always return all posts.

I'm working on some matching improvements to Micropublish to add post-status and visibility to help test this. https://mpubl-br-v3.herokuapp.com