Network/multi-user program

[memilanuk]

On 07/21/2014 11:26 AM, Chris Angelico wrote:
> On Tue, Jul 22, 2014 at 4:16 AM, Monte Milanuk <memilanuk at invalid.com> wrote:
>> On 2014-07-21, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Tue, Jul 22, 2014 at 2:07 AM, Monte Milanuk <memilanuk at 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