Talk:GEPS 013: Gramps Webapp
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.
- Gramps hardening. Once we expose Gramps online, even in a supposedly "read-only" mode, and let anyone out there submit inputs to it, we open ourselves to lots of well-known exploit techniques, like any other web application out there. We have to protect the server capacity resources (CPU, data, and bandwidth), server assets (data - so that we don't have, e.g., an option in the web app that allows to leak data from the DB or the server's filesystem), clients (so that we don't make it easier to attack somebody else or extract data from a client's web browser in a multi-staged attack), other servers (so that, for instance, some webapp command doesn't cause our webapp to make a DoS attack against another machine), etc. Some of the threats might be mitigated by the appropriate Django mechanisms, but I haven't looked deeply. Last, but not the least, we need regression testing assuring that the security guarantees set forward by the features in the bullets above actually hold (e.g., that only the administrator may change the server settings and provision other user accounts).
This means we need security threat modelling, penetration testing, and a security code audit. Until then, I wouldn't recommend anybody to deploy it live.
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.
Maybe it can also be possible to implement a GeoView like (Gramps-Gtk program) ?
There is a nice project using Django framework and a Python module for generating maps of cities or towns, including index of streets, from OpenStreetMap data. There is some samples (around the world) on this page .
Where are they ?
Strange, I cannot find a lot of demos on the web anymore ? Some urls are no more active. I added a well known (for french) collaborative database, which uses Geneweb engine as additionnal sample.
- It seems to be fixed on last versions?