Commit ff262053 authored by Per Cederqvist's avatar Per Cederqvist
Browse files

(Membership visibility): New chapter. (Bug 693).

parent bf9ca5e3
......@@ -394,6 +394,7 @@ The most up-to-date version if this document can always be found at
* Name Expansion:: Looking up the name of a conference or person.
* LysKOM Content Types:: Predefined content types for articles.
* The User Area:: Store client-specific settings in the server.
* Membership visibility:: How the security features interacts.
* Writing Clients:: A few tips for client writers.
* Importing and Exporting E-Mail:: A few thoughts on e-mail integration.
* Future changes:: The protocol is not yet perfect.
......@@ -9081,6 +9082,96 @@ The default mark to set on marked texts.
@node Membership visibility
@chapter Membership visibility
The details of the security model isn't properly documented. Much
information can be extracted from various parts of the protocol
specification, but there is no complete overview. In time, this
chapter may become such an overview. For now, it only defines
when a membership is visible.
The various requests that return information about a membership can be
grouped in three categories:
@itemize @bullet
@item Category 1: given a conference, list (some of) the members.
@itemize @bullet
@item @reqlink{get-members}
@item @reqlink{get-members-old}
@end itemize
These requests fail if the conference is secret and you don't have
access to it, even if a membership should be visible to you according
to the rules below.
@item Category 2: given a person, list (some of) the conferences that
the person is a member of.
@itemize @bullet
@item @reqlink{get-membership}
@item @reqlink{get-membership-old}
@item @reqlink{get-unread-confs}
@end itemize
@c FIXME (Bug 70): Should secret persons be allowed?
These requests fail if the person is secret and you don't have access
to it, even if a membership should be visible to you according
to the rules below.
@item Category 3: given a person and a conference, return the membership.
@itemize @bullet
@item @reqlink{query-read-texts}
@item @reqlink{query-read-texts-old}
@end itemize
These requests follows the rules below exactly.
@end itemize
The rules for membership visibility is given below. In the
explanation, the variables @var{C}, @var{P} and @var{V} are used like
this:
@itemize @bullet
@item a conference @var{C}
@item a person @var{P} who is a member of the conference @var{C}
@item a viewer @var{V} who wants to find out about @var{P}:s
membership in @var{C}.
@end itemize
The following flags also influences how much @var{V} can see:
@itemize @bullet
@item the @field{unread-is-secret} flag of @var{P}
@item the @field{secret} flag of @var{P}:s membership in @var{C}
@end itemize
The following rules determines if a memberhip is visible to @var{V}.
The first rule that matches is used.
@itemize @bullet
@item
If @var{V} is supervisor of @var{P}, then the membership is visible.
Both the @field{unread-is-secret} and @field{secret} flags are
ignored.
@item
If @var{V} is supervisor of @code{C}, then the membership is visible.
The @field{secret} flag is ignored. The @field{unread-is-secret}
flag is honored.
@item
If @var{V} is allowed to see both @var{P} and @var{C}, and if
@field{secret} is unset, then the membership is visible. The
@field{unread-is-secret} flag is honored.
@item
Otherwise, @var{V} is not allowed to se the membership.
@end itemize
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment