Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!nerim.net!novso.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path: <python-python-list@m.gmane.org>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.009
X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'frameworks': 0.05; 'class,': 0.07; 'see:': 0.07; 'python': 0.09; 'creator': 0.09; 'django,': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'stored': 0.10; 'itself.': 0.11; 'dump': 0.16; 'identifier.': 0.16; 'planner': 0.16; 'privilege': 0.16; 'received:80.91.229.3': 0.16; 'received:plane.gmane.org': 0.16; 'wed,': 0.16; 'instance,': 0.17; "shouldn't": 0.17; 'subject:request': 0.17; 'feb': 0.19; 'appropriate': 0.20; '+0000': 0.20; 'permission': 0.20; 'sort': 0.21; 'meant': 0.21; 'fixing': 0.22; 'keys': 0.22; 'permitted': 0.22; 'planned': 0.22; 'work,': 0.22; 'mention': 0.23; 'least': 0.25; 'bugs': 0.27; 'handling': 0.27; '(as': 0.27; 'header:X -Complaints-To:1': 0.28; 'this?': 0.28; 'record': 0.28; 'objects': 0.29; 'probably': 0.29; 'classes': 0.30; 'code': 0.31; 'system,': 0.32; 'more,': 0.32; 'could': 0.32; 'dates': 0.33; 'url:home': 0.33; 'handle': 0.33; 'problem': 0.33; 'to:addr:python-list': 0.33; 'operations': 0.33; 'filter': 0.35; 'table': 0.35; 'received:org': 0.36; 'really': 0.36; 'but': 0.36; 'data.': 0.36; 'anything': 0.36; 'should': 0.36; 'charset:us-ascii': 0.36; 'unable': 0.36; 'itself': 0.37; 'two': 0.37; 'data': 0.37; 'subject:: ': 0.38; 'mean': 0.38; 'object': 0.38; 'some': 0.38; 'to:addr:python.org': 0.39; 'application': 0.40; 'header:Received:5': 0.40; 'think': 0.40; 'most': 0.61; 'between': 0.63; 'management': 0.65; 'privacy': 0.65; 'secure': 0.67; 'direct': 0.69; 'soon': 0.70; 'foreign': 0.72; '(each': 0.84; '2013': 0.84; 'log-in': 0.84; 'route': 0.84; "they'd": 0.84; 'transmitting': 0.84; 'capability': 0.91; 'cryptography': 0.91; 'dennis': 0.91; 'received:108': 0.91; 'safe.': 0.93; 'tied': 0.93
X-Injected-Via-Gmane: http://gmane.org/
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: Improve reduce functions of SQLite3 request
Date: Wed, 06 Feb 2013 12:26:12 -0500
Organization: > Bestiaria Support Staff <
References: <kelbl0$1jv$1@nerdhammel.gnuher.de> <mailman.1317.1359915110.2939.python-list@python.org> <keogmb$dml$1@nerdhammel.gnuher.de> <mailman.1331.1360010737.2939.python-list@python.org> <kepbak$ne$1@nerdhammel.gnuher.de> <mailman.1340.1360021639.2939.python-list@python.org> <ket762$vam$1@nerdhammel.gnuher.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Gmane-NNTP-Posting-Host: adsl-108-79-219-81.dsl.klmzmi.sbcglobal.net
X-Newsreader: Forte Agent 3.3/32.846
X-No-Archive: YES
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.1421.1360171591.2939.python-list@python.org>
Lines: 50
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1360171591 news.xs4all.nl 6958 [2001:888:2000:d::a6]:32778
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:38296

On Wed, 6 Feb 2013 09:18:58 +0000 (UTC), Steffen Mutter
<steffen@webanimations.de> declaimed the following in
gmane.comp.python.general:

> Actually I am fixing bugs and think about the user managment and
> permission handling and privacy of data.
> 
> Just give you a peek:
> referees need to be kept safe. 
> But they need to be planned and stored in the DB.
> How to handle this?
> I think I use GnuPG. 
> Every referee and referee-date-planner needs a private and public key so
> only these persons can see it, the planner every referee he dates and
> the referee only these games he is planned for.
> 
>  You see: a lot of work to do - after fixing some bugs and get the
> <select id="team" size=7 multiple> to work, that will be a big task... 

	If this is meant to be a web-based system, you probably should be
looking into using some sort of framework: Django, Zope/Plone, etc.
These often have at least two classes of users (controlling what
operations they are permitted to perform), if not more, with session
management controls.

	Most of these frameworks use some form of object-relational mapper
(ORM) to go between Python code objects (each table is a class, and each
record is an object instance, to put it is very general terms) and the
database itself.

	Problem with going that route is that you really need to normalize
the database (as soon as you said you just dump everything into one
table I shuddered), since a lot of the capability is tied to using
foreign key linkages to filter data.

	You shouldn't need the public key cryptography system since the
application itself should be able to control visibility of the data
using some privilege table and a log-in identifier. Using PKCS to
encrypt data would mean the creator of that data would be unable to edit
it, as they'd need the private key to decrypt it for editing. Not to
mention you'd need to have a way of transmitting the keys to the
appropriate people. If you kept the keys on the database, you'd then
need a secure way to ensure the proper key for the user was picked --
anything that secure could be used to control the direct access to the
data itself without encrypting it.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/