[Glass] Help defining gemstone users for a multi-user app

Mariano Martinez Peck marianopeck at gmail.com
Mon Jan 6 09:08:30 PST 2014

On Mon, Jan 6, 2014 at 2:08 PM, Mariano Martinez Peck <marianopeck at gmail.com
> wrote:

> On Mon, Jan 6, 2014 at 1:32 PM, Otto Behrens <otto at finworks.biz> wrote:
>> > I want to have a user like DataCurator, let's say 'MyAppAdmin' that is
>> > allowed to create classes, update code, connect to GemTools, and other
>> > stuff. Then, I want a normal user (without any privilege) say
>> 'MyAppWebUser'
>> > and the seaside gems of my app will be run with such a user.
>> We did not bother in our application. We just use DataCurator for
>> both. We do not use GemStone database users for user management, so
>> the GS user credentials is unknown to the user of the application.
> Here's the same. I consider GemStone users as a relational DB user. Users
> of the app are managed at my side (app).
>> In
>> our case, we just cannot distinguish between GS users in the same
>> database because all users share at least some of the data. We have
>> another User class and we control who sees what from the application.
>> Let me know if I can show you more here, but it sounds as if you have
>> a different setup.
> I think it is more or less similar. I *could* use same user for both
> things (managing gems and admin tasks), but I kind of think that the
> separation would give me some me security.
> One of the things is that in the app, you can define certain rules which
> at the end are smalltalk closures. Ideally, I should validate and make sure
> that nobody can write a dangerous script in there. But....that's hard.
> Until then, having a normal user running the gem helps me a lot to this
> because I know there are several things the user won't be able to do
> because of the gemstone users the gems are running with.
> But yeah, it complicates other stuff, like how to share the globals...
>>  > So....how can I define these 2 users? I guess I can create a user and
>> assign
>> > the DataCuratorGroup or policy. Is there anything specially recommended
>> for
>> > this? (how to create a typical "admin" user)
>> >
>> > Anyway... still..each of these users will have their own UserGlobals.
>> If I
>> > load the code with 'MyAppAdmin' then it will be in the UserGlobals of
>> that
>> > user and not available to 'MyAppWebUser'. What do I need to do? Put
>> > everything under Published list instead of UserGlobals?   So basically,
>> I am
>> > asking how can I have an admin user and a none-admin both sharing the
>> same
>> > UserGlobals (or similar).
>> I would say if you need separate data environments for your users,
>> then yes, a good GemStone way is to use Published for the code and
>> each user with his own UserGlobals (not shared). Published could be
>> assigned to a segment with the DataCuratorGroup permissions and read
>> permissions for MyAppWebUser.
>> I would not know how to use class / class inst vars though - I don't
>> think that's possible in this setup, because it would refer to the
>> same object which will share the data. You'll have to create a
>> dictionary of some sort that you put into UserGlobals for your data /
>> instances of objects.
> Indeed. There is something I didn't mention because I was going to ask
> that in a later thread. But.... a second requirement is that I will have a
> few instances of the same app. So, same code, running with different users.
> I need this to get a really isolated environment.  So for each of my app
> installation, I need its own 'MyAppAdmin' like and its own 'MyAppWebUser'
> like. I *could* use same user for both things as you suggest.  For the
> moment, as a first step, I don't care if I need to load all glass/seaside
> for each user (or pair of users). This is the easiest. I know I could share
> all glass/Seaside code for all users (or all pais of users), but I need to
> be very very careful about all class vars usage. So that's why as a first
> step, I can have duplicated all glass/seaide code.
> Thanks for the help!
> --
> Mariano
> http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140106/87cdc2e9/attachment.html>

More information about the Glass mailing list