Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: memilanuk <memilanuk@gmail.com>
Subject: Re: Network/multi-user program
Date: Wed, 23 Jul 2014 07:14:19 -0700
References: <slrnlsqelq.evp.memilanuk@machin-shin.milanuk.lan> <CAPTjJmqmGEVr8-DApUf5zUt3QpL+9=rOiweyzc0Z9thtBEpO=w@mail.gmail.com> <slrnlsqm8h.evp.memilanuk@machin-shin.milanuk.lan> <CAPTjJmrnXKpXraRbBwY=HjU08V1OQJvEBObToJaPbOpyogid5A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <CAPTjJmrnXKpXraRbBwY=HjU08V1OQJvEBObToJaPbOpyogid5A@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.12242.1406124874.18130.python-list@python.org>
Lines: 67
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:75087

On 07/21/2014 11:26 AM, Chris Angelico wrote:
> On Tue, Jul 22, 2014 at 4:16 AM, Monte Milanuk <memilanuk@invalid.com> wrote:
>> On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:
>>> On Tue, Jul 22, 2014 at 2:07 AM, Monte Milanuk <memilanuk@invalid.com> wrote:
>>>> So I guess I'm asking for advice or simplified examples of how to
>>>> go about connecting a client desktop app to a parent/master desktop app,
>>>> so I can get some idea of how big of a task I'm looking at here, and
>>>> whether that would be more or less difficult than trying to do the
>>>> equivalent job using a web framework.
>>>
>>> Easier way: Don't have a "master desktop app", but instead have a
>>> master database. Since you're posting this to python-list, I'll assume
>>> you currently intend writing this in Python; you can make a really
>>> simple transition from single-user-single-desktop to a networked
>>> system, although of course you'll want to think in terms of multiple
>>> users from the start.
>>
>> So... if everybody is using the same application to access the same
>> database, how would you prevent say, a data entry user from accidentally
>> breaking something above their pay-grade?  Set up some sort of
>> role-based privilege system to limit them to write access for some
>> portions and read-only for others?
>
> That would be one way, yes. The first question you'd need to ask is:
> How do you know who's data-entry and who's admins? As soon as you
> solve that (probably with some sort of login), you tie the access
> level to that.

Given the small user base and the nature of the events, volunteer staff, 
everybody knowing everybody, etc. its pretty much a matter of the match 
admin saying "You, you and you - data entry" ;)

> If you need absolute security, you would have the user enter a login
> and password which would actually be the database credentials. Then
> you grant exact rights in the database manager, permitting ONLY what
> that user is allowed to do. It's then utterly impossible, even for
> someone who knows Python and SQL, to do damage.

Intriguing... and probably the most technically correct way as far as 
role-based access.  But also very unlikely that most of the end-users 
would be able to set up the DB correctly.  Just sayin'...

> But more likely, what
> you really want is a cut-down UI that simplifies things: if the user
> is data-entry level, you take away all the admin-type options. It
> might be possible to fiddle around in internals and gain elevated
> access, but that's not an issue in many environments.

That sounds very much like what I'm thinking of... maybe a token nod @ 
security with a passwd for 'admin' and 'data-entry' roles to keep idle 
passers-by from snooping or diddling with things they shouldn't.  Even 
if it just greyed-out / disabled buttons, tabs, etc. based on role that 
would probably meet needs.

> In any case, these are issues you'd need to figure out regardless of
> the development model. Ultimately, you could treat the entire
> computer, network, database, etc as a black box, and just look at two
> entities: the human, and the UI s/he is using. All permissions issues
> can be explained at that level.

Not really clear on what you're talking about on this part...

Monte