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

Mon Jan 6 12:21:20 PST 2014

----- Original Message -----

| From: "Mariano Martinez Peck" <marianopeck at gmail.com>
| To: "Otto Behrens" <otto at finworks.biz>,
| glass at lists.gemtalksystems.com
| Sent: Monday, January 6, 2014 9:08:30 AM
| Subject: Re: [Glass] Help defining gemstone users for a multi-user
| app

| 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.
| 
If you are allowing users at some level to write arbitrary Smalltalk, then the security afforded by GemStone users is the ticket:) 

| | | > 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.
| 

If you are going to share code that you didn't write, you _can_ change the references to class variables, etc. to message sends where you arrange to do some user-specific shenanigans, like referencing UserGlobals (which is automatically switched on a per user basis) ... 

If you don't want to go around and modify everything in Seaside, there is a facility in 3.x where you can arrange for class variable references to be compiled using a message send and a custom association class. 

Normally, class var associations are compiled using a known kernel class and the value slot is directly accessed without a message send ... By setting a couple of flags and using a custom Association class, the compiler will use your association class and the compiled reference will use a message send. This means that in your custom Association the value message can be used to do a lookup in UserGlobals and get per gemstone user class variable associations ... 

I did this with Pier a couple of years ago and while it didn't address every shared data issue, it did address the vast majority of issues .... I've still got the code lying around if you want to play with it.... 

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