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

Mariano Martinez Peck marianopeck at gmail.com
Mon Jan 6 13:02:17 PST 2014

On Mon, Jan 6, 2014 at 1:34 PM, Dale K. Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> If you are going to share code between users, then I would suggest that
> you start by installing the GLASS/seaside code into a SymbolList that is
> not UserGlobals and perhaps even use a Gemstone user that is not
> DataCurator.


> The attached script creates a 'glass' user with the same permissions as
> DataCurator and loads the GLASS code  (starting with a
> $GEMSTONE/bin/extent0.dbf) into a GLASS SymbolDictionary.
Dale, I have just tried that and indeed it was quite helpful. At least, I
was able to create a user with DataCurator like privileges, load my code
there, and run my app. So I could have "two instances of my app running
with 2 different gemstone users". So it was quite a good step.
A few notes:

1) could this script be committed somewhere to the public? Maybe to the
same place were you were grouping scripts like the purge logs from Norbert?
2) I had to execute: "export upgradeDir=$GEMSTONE/upgrade"    before
running the script..otherwise, #upgradeDir doesn't exist.
3) After finishing the load, I noticed that I have 2 entries called 'GLASS'
in my SymbolList. In addition, the SystemDictionary created for #'GLASS'
was actually a SymbolDictionary whose key was #'GLASS' and the value was a
reference to itself (the SymbolDictionary). So class in there..... In fact,
classes were loaded into the third dictionary, which is....UserGlobals.   I
guess something is wrong here since I expect all glass classes to be in
#'GLASS' SymbolDictionary, right?

Once you've done this, you can arrange to install the glass users's #GLASS
> SymbolDictionary into another users SymbolList and thus share the code ...
> The `web` user will have to have write permission on all of the slots of
> the Seaside code, so it might make sense to load the seaside code into the
> `web` users space directory ...
> I have to get ready for work right now, so the additional instructions
> will have to wait:)
> In the meantime, though I would like to better understand the rationale
> for separate GemStone users ... things will be much simpler if you done
> have separate users, so I would think that you'd need a good reason for the
> extra hassle:)
Well, the reason so far is security. Mostly because users are able to
define they own rules. I answered this later on in another entry of this

Thanks for the help

> A diagram of the shared and isolated data would help me understand how the
> code/users/data should be structured ...
> Dale
> ------------------------------
> *From: *"Mariano Martinez Peck" <marianopeck at gmail.com>
> *To: *glass at lists.gemtalksystems.com
> *Sent: *Monday, January 6, 2014 8:04:40 AM
> *Subject: *[Glass] Help defining gemstone users for a multi-user app
> Hi guys. I am finding troubles to understand how should I organize my
> users and UserGlobals for my app.
> 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.
> 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).
> Thanks in advance,
> --
> Mariano
> http://marianopeck.wordpress.com
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

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

More information about the Glass mailing list