memilanuk at gmail.com
Wed Jul 23 16:14:19 CEST 2014
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...
More information about the Python-list