[Glass] DataCurator and then own user?

Hi guys,

---

From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 3, 2013 12:53:18 PM
Subject: [Glass] DataCurator and then own user?

Hi guys,

So say I have a typical Seaside app running with a typical DB. If I understand correctly, DataCurator is the default user I can use and it has many of the privileges a typical admin account would have. The question is when you want to actually run the application... So i wonder:

1) to load code into gemstone and prepare everything we use DataCurator or any user with DataCuratorGroup ?

I think I answered part of these questions in my previous post ...you can arrange to share the code in DataCurator with multiple users.

A couple of years ago I set up a GemStone system running Pier where each a separate instance of Pier was used by a separate GemStone user, so I've been through this drill and one of the techniques I used was to replace all class var references (association from class variable dictionary embedded in compiled method) with a UserGlobals association ... in this way each GemStone user had completely isolated state .... it didn't solve all of the problems, but it saved me from dircetly modifying the Pier code (in the hundreds(?) of places where class vars were directly referenced:))

2) When we run the application, we create our own user to run it? (with no DataCuratorGroup) ? I mean...a more restricter user... ?  If true, then I guess I should analyze which permissions  and security policy to give it, right? Is there a typical setup for this kind of user?

For the user/db trick to work you do have to have a gem that is logged in with user's credentials to access the data ... so depending upon the best combo for your particular case, you could run one or more gems per gemstone user (following along the complete isolation model), or you could arrange to use a per user service vm to do the real work and shared seaside gems to handle the GUI work (incomplete isolation) ...

Dale