Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read only and/or snapshot sharing #91

Open
cben opened this issue May 21, 2015 · 1 comment
Open

Read only and/or snapshot sharing #91

cben opened this issue May 21, 2015 · 1 comment

Comments

@cben
Copy link
Owner

cben commented May 21, 2015

In some cases it's desirable to share a document without giving write access.
How to implement this on top of firebase security rules? The straightforward way is adding an edit_key child and requiring == to key users supplies. This would mean that original ?doc=foo url becomes read-only, and ?doc=foo&edit_key=bar is needed to edit. Avoiding this — letting original writable URL stay writable — probably requires moving the firepad history to a new place (which might break concurrent/offline edits at the moment it's done).

  • Creating completely read-only pages is somewhat contrary to my goals for Mathdown; ideally I'd want main text to be read-only but allow comments. My current plan for comments (Author-attributed text #41) is simply part of the text with special convention to indicate author — this would be tricky to support.
    • It might be easy to support comments outside the main text via Firepad rich text support. I don't really want to go this way though.
    • I think I'll settle for append-only comments. Those would be left outside the main document model, similar to the planned from->append fallback for users without javascript (Spiderable documents (content in HTTP response) #7).
  • A related feature would be sharing a specific snapshot frozen in time (like pastebin sites).
@cben
Copy link
Owner Author

cben commented May 21, 2015

An alternative access model is restricting editing (or all access in the case of #92) to an ACL of specific logged-in users (once we have those — #50).
I'm less inclined to support this but once a user visits a "priviledged" link with edit key, the account should "bookmark" this link which essentially gives this user access.

[Why do I prefer capability links to user identity? To some degree this is just gut feeling, but (1) same access controls apply to users that haven't created an account — or have but are not logged in right now (2) access can be delegated, which is a feature ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant