Talk:GEPS 013: Gramps Webapp

From Gramps
Revision as of 08:01, 7 August 2009 by Dsblank (talk | contribs) (Talk:GEPS 013: Server mode moved to Talk:GEPS 013: GRAMPS Webapp: The server mode was too hard... need a real framework.)
Jump to: navigation, search


Security is a big enough issue for a server that it probably ought to be its own section rather than just a bullet point under "Discussion". Obviously there is a LOT of other work to be done still on this great concept. But I wanted to toss out some thoughts on what a GRAMPS Server security model may (or may not) support, since having these ideas in mind might affect other design decisions along the way. It's always good to have security in mind while designing a server. And yes, some of what I describe here are my favorite details of the PhpGedView security model. It is excellent for sharing data with family members, but GRAMPS is far better for maintaining the data. Having a GRAMPS Server someday is a wonderful dream that would end the need to convert my data in order to share it!

  • User accounts. A server really must support multiple users with different credentials and access permissions, even if one chooses not to configure it for collaboration (only one user with write permission). This is the primary reason I dropped GeneWeb for PhpGedView some time ago.
  • Optional anonymous user. Some databases would be appropriate to drive a fully-public website. Others would not. If enabled, the anonymous user would have the same configurable access permissions as any other user (probably configured very restrictively).
  • Ability to attach a given user account to a specific person in the database.
  • Ability to choose whether a given user can see info about living people.
  • Ability to control how far from their "home" Person a given user can see info about living people.
  • Ability to choose whether a given user can edit.
  • Ability to control how far from their "home" Person a given user can edit.
  • Ability to make a given user an admin, so they can access and edit server settings and user accounts (perhaps separate settings for server and user admin?).
  • Revision control. Like this wiki, the ability to retrieve the history of any given database object, and see what changes were made, when, and by whom.

There are surely plenty of other possible capabilities, but these are what come to mind right now as being most important for preserving the privacy and integrity of the data.