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

Content sharing #449

Open
gallayl opened this Issue Aug 21, 2018 · 7 comments

Comments

@gallayl
Copy link
Contributor

gallayl commented Aug 21, 2018

The result of the latest UX Research:

image.png

This is how we currently plan to create the sharing feature in sensenet.

Entry point

  • Sharing starts on a content.
  • Display a list of previous sharing records with Delete option.
  • Sharing modes
    • anyone with the link: even visitors, no authentication required
    • authenticated users only (anyone signed in: the Everyone group)
    • specific persons: identified by e-mail address, requiring authentication
  • Access levels for now
    • view content
    • edit content

Managing sharing on the client

We will create custom actions for getting/setting sharing data, accessible only for certain groups.

Question: action access (who can share a content?)

This can be strict for now, later we may lower the bar - for example let target users share it further.

  • users with SetPermission rights on the content?
  • only the Owner of the document?
  • members of a certain group/role?

Sharing data

The stored data is filtered when sent to the client, only info accessible for the current user is provided.

  • token (email, random word)
  • identity (user/group id or Somebody)
  • mode (public/authorized/private)
  • level (open/edit/...)
  • who shared it (or Somebody)
  • when was it shared
  • expiration date

Example payload for client actions

{
  "d": {
    "__count": 2,
    "results": [
      {
        "Id": "42d187a1-c2a7-4820-83cc-9127433f1eba",
        "Token": "abc1@example.com",
        "Identity": 123,
        "Mode": "Private",
        "Level": "Open",
        "CreatorId": 1,
        "ShareDate": "2018-10-18T10:04:14.7924455Z"
      },
      {
        "Id": "6ad87747-8354-41e6-a263-600a0adf81f5",
        "Token": "abc2@example.com",
        "Identity": 8,
        "Mode": "Authenticated",
        "Level": "Edit",
        "CreatorId": 42,
        "ShareDate": "2018-10-18T10:08:54.2348904Z"
      }
    ]
  }
}

Sharing storage and management

  • sharing info is stored on the target content in a new strongly typed sharing info property stored as longtext
  • new fake field for indexing and exporting/importing sharing info (not 'based on the property')
    • the field is hidden, it does not contain and expose the raw data!
    • export/import is allowed for admins only, id<-->path conversion is necessary
    • later: export partial sharing info, without dates and 'user who shared' info
  • query: fake field index handler creates index terms

Hooks for changes

  • user email changes
  • user is deleted
  • ???

@gallayl gallayl added this to the Sprint 165 milestone Aug 21, 2018

@gallayl gallayl added the discussion label Aug 21, 2018

@herflis herflis modified the milestones: Sprint 165, Sprint 166 Aug 22, 2018

@gallayl

This comment has been minimized.

Copy link
Contributor

gallayl commented Aug 30, 2018

Update: We've agreed to modify the specs for the Share function and work only with e-mail addresses.

@tusmester

This comment has been minimized.

Copy link
Member

tusmester commented Aug 30, 2018

Why are we excluding usernames, full names or any other field that can be used to identify existing users?

@kultsar

This comment has been minimized.

Copy link

kultsar commented Aug 30, 2018

For existing users, in my opinion, any fields that uniquely identify them, could be fine. E-mail addresses, usernames, etc. Full names do not uniquely identify them, I guess.

@gallayl

This comment has been minimized.

Copy link
Contributor

gallayl commented Aug 30, 2018

Consider the following scenarios:

  1. The user who want to share the doc doesn't have permission to actual user content and should not know if a user is already registered with that name
  2. The user is not registered yet, but you want to share the doc with her. Maybe you have to create a temporary / placeholder user and notify her. If she completes her registration (e.g. with Google OAUTH) we should be able to correlate with an unique key in an authorized way.
  3. There can be multiple users registered with the same full name / display name

We should talk about how we threat the login name / email address relationship. We use email addresses as login names in the DMS Demo at the moment to ensure the uniqueness within the public domain.

We've agreed that we can implement a contact list (private, workspace-bound or whatever) and use it to pick users for sharing in a later version.

@tusmester

This comment has been minimized.

Copy link
Member

tusmester commented Aug 30, 2018

Sorry, when I said identifying users I meant only on the sharing GUI :). I was referring to how I (as the document owner) can search for users when sharing: by email, or by username/fullname. Of course this should only show me users that I have access to.

If you do not have access to an existing user but you provide his email address, that can be handled in the background, the client should not know anything about how we store sharing info.

@kultsar

This comment has been minimized.

Copy link

kultsar commented Sep 3, 2018

Access types for now:

  • view content
  • edit content

Share types:

  • anyone with the link: visitor, no authentication required
  • specific persons: identified by e-mail address of a registered user, requiring authentication

URL contains no human-readable data (nothing about content or user data should be inferred)
Separate URL is generated based on GUIDs generated for each shared content and access type and share type combination. At present this can mean:

  • 1 GUID/URL for visitors with view access
  • 1 GUID/URL for visitors with edit access
  • 1 GUID/URL for identified users with view access
  • 1 GUID/URL for identified users with edit access

@kultsar kultsar modified the milestones: Sprint 166, Sprint 167 Sep 5, 2018

@gallayl gallayl referenced this issue Sep 12, 2018

Closed

[DMS] Share GUI #448

4 of 4 tasks complete

@kultsar kultsar modified the milestones: Sprint 167, Sprint 168 Sep 19, 2018

@kultsar kultsar added the Epic label Oct 3, 2018

@kultsar kultsar changed the title [DMS] - Content sharing Content sharing Oct 3, 2018

@kultsar kultsar modified the milestones: Sprint 168, Sprint 169 Oct 3, 2018

@kultsar kultsar added backend and removed backend labels Oct 8, 2018

@tusmester

This comment has been minimized.

Copy link
Member

tusmester commented Oct 9, 2018

Discussion memo
  • security component is almost ready (permission category feature), except permission queries
  • sharing record is stored on the target content in a new strongly typed property (sharing info?) stored as longtext
  • new fake field for indexing and exporting/importing sharing info (not 'based on the property')
    • the field is hidden, it does not contain the raw data!
    • export/import is allowed for admins only, id<-->path conversion is necessary
    • later: export partial sharing info, without dates and 'user who shared' info
  • query: fake field index handler creates index terms
  • sharing info is edited with custom actions, not through a generic OData field.

Sharing info

  • token (email, user or group id, random word)
  • mode (public/authorized/private)
  • level (open/edit/...)
  • who shared it
  • when was it shared
  • expiration

Hooks

  • user email changes
  • user is deleted

@kultsar kultsar modified the milestones: Sprint 169, Sprint 170 Oct 17, 2018

@kultsar kultsar modified the milestones: Sprint 170, Sprint 171 Nov 5, 2018

@kultsar kultsar removed this from the Sprint 171 milestone Nov 14, 2018

@kultsar kultsar referenced this issue Nov 18, 2018

Closed

deleteme #418

This was referenced Nov 19, 2018

@kultsar kultsar removed the discussion label Dec 10, 2018

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