Page MenuHomewrite.as

User-only visibility setting
Open, HighPublic

Description

Overview

Add a blog visibility setting that makes the blog and all posts available only to other registered users on the instance.

Background

It should be possible to run an instance in an internal environment, where writing is only shared with other registered users.

Implementation

This should be a new instance-level configuration setting, something like internal_only. If it's true, blogs and their pages should only show content when requester is authenticated as a user (owner or not) on the instance. If not authenticated, these pages will always return a 404.

This setting should be checked:

  • On the web
  • Via the API

Also when true:

  • Posts should never federate
  • Public stats should never show

Event Timeline

matt created this task.May 4 2019, 1:00 PM
matt triaged this task as High priority.
matt moved this task from Far Future to Soon on the WriteFreely board.May 6 2019, 1:50 PM
matt claimed this task.May 12 2019, 11:55 PM
matt added a subscriber: agd.May 14 2019, 4:03 PM

@agd Working on this now. I started off making it so that when a user is unauthenticated, all blogs and posts return a 404 (to not reveal the existence of any blog). But I'm wondering if it'd be better to send a user to the login page, instead, for better convenience. If so, we could still obscure existence of individual blogs by simply sending all routes to the login page when unauthenticated. This could be the same for the API -- all routes would just require authentication.

What do you think?

agd added a comment.May 14 2019, 7:33 PM

So this is likely a comment that is more meta than the ticket itself, but I think that I'd like the "story" to be something like:

Overall Goals

  • should not "leak" presence of things via URL/API like username, or other identifiable things like "title"
  • should always redirect users to either an instance "splash" page or the login page.

In fact, with gitea, we're actually specifying the default page to be "explore", which when you do that in cohort with having a registration disabled instance always defaults to prompting login for non authenticated users (because you're default route requires login). If I didn't specify this then you get some sort of overall gitea page, which is cute... but isn't customizable without me mucking hard in the template. It'd be nice to be able to choose between forced login, or a splash page that explains the reasoning for the instance... like someone discovers it on line and wonders what it is, you could explain your instances reason for existence (this is more for the case where you want people to request registration).

For Unauthenticated Users

  • entry point is someone linking a URL
  • check session/login, if not, rewrite them to a login prompt
  • post auth rewrite back to url they were seeking

For Administrators

  • simple "toggle" for federated or non-federated "mode" where you can decide that your entire instance of "write.as" tooling is non-federated (this would be nice on all tooling, e.g. snap.as)
  • registrations + can be disabled entirely for the instance, use a CLI or GUI based user creation system (default closed instance) + can be set to "approval" where someone can request an account and a set of admins an approve those accounts (this is more complex and not required for my goals, but seems like a "closed" community would be interested in this type of workflow)
matt added a comment.May 17 2019, 8:31 PM

Thanks, this all makes sense.

I'm going to send users to the login page when unauth'd for now, and then we can see how that works in combination with T574 to determine whether or not more landing page customizability is needed.

As for the administrator items:

  • We currently have a federation config flag that takes care of this (and agreed, it should be on all tooling).
  • Registrations currently can be disabled with the open_registration config flag, and users can always be created by running writefreely --create-user username:password or generating an invite link (config docs and command docs).

I do like the idea of an approval workflow! I'll keep this in the back of my mind to see how it might work into larger plans.

matt added a comment.EditedMon, Jun 17, 12:50 AM

Just opened a pull request (GH#123) for this. I still need to verify that data isn't leaking on some ActivityPub endpoints (namely nodeinfo and webfinger), but the core of everything is there and ready to try out.

matt added a comment.Mon, Jun 17, 1:27 AM

Addressed those issues in most recent commits.