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

Tue Jan 7 11:48:13 PST 2014

On Tue, Jan 7, 2014 at 4:15 PM, Dale K. Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> ------------------------------
>
> *From: *"Mariano Martinez Peck" <marianopeck at gmail.com>
> *To: *"Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
> *Sent: *Tuesday, January 7, 2014 10:44:42 AM
> *Subject: *Re: [Glass] Help defining gemstone users for a multi-user app
>
>
>
>
> On Mon, Jan 6, 2014 at 7:45 PM, Dale K. Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>>
>>
>> ------------------------------
>>
>> *From: *"Mariano Martinez Peck" <marianopeck at gmail.com>
>> *To: *"Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
>> *Cc: *glass at lists.gemtalksystems.com
>> *Sent: *Monday, January 6, 2014 1:18:45 PM
>> *Subject: *Re: [Glass] Help defining gemstone users for a multi-user app
>>
>>
>>
>>
>> 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.
>>>
>>> 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 ...
>>>
>>>
>> Hi Dale. This sentence "so it might make sense to load the seaside code
>> into the `web` users space directory" confuses me.
>>
>> I mentioned this because the Seaside code has a fair amount of state in
>> things like class variables that would make trying to share those globals a
>> bit difficult ... these shared globals exist in GLASS as well, but there
>> just aren't quite as many - the bulk of the shared variables in the base
>> GLASS classes are used mainly by the development tools: GemTools or tODE,
>> so don't impact deployed apps as much ... Much of the Seaside state just
>> can't be shared ...
>>
>>
> OK got it. Problem is I do have some other class variables as well....
> Also...I like the fact that I can keep separated code for each user since
> that allows me to update code for one but maybe not for other etc. Right
> now I need to go with the easiest possible path, and that seems to be to
> have GLASS/Seaside/MyCode loaded in each web user, right?
>
> I talked this over with Allen and there is no clean way separate the
> GsObjectSecurityPolicy for the code and the class vars, etc.
>
> So the easiest path will probably be the dynamic literal variable path ...
> you can still install the whole stack on a per user basis (as DataCurator),
> but use the dynamic literal vars to isolate the code and data ...
>

Sorry Dale, but I am afraid I am lost here. If I were able to install the
whole stack on a per user basis (as DataCurator), why would I need the
dynamic literal vars to isolate the code and the data??? If I have same
(but not #==) class (which has a classVar) in 2 different SymbolDictionary
from 2 different users, wouldn't each class var point to the slot of of
that class? So why would be a problem having same class in other
SymbolDictionary of another user? or in other words, why would I need the
dynamic literal vars stuff? Wouldn't it be like 2 isolated
SmalltalkDictionaries running?

> This also brings up the question of how are you going to give users the
> ability to customize their access to data.
>

Well.... the data associated to a site will be placed in UserGlobals. But
it should be only readable/writable by that 'web' user and (if it exists)
the 'glass'/admin one. I still need to investigate how to do this. As a
first step, I can start by having same user 'glass' for both things, for
the web and for the admin. This is not ideal, but at least as a first step.

> If you are planning to compile code then they will need code modification
> privileges ...
>
>
I thought about the same, but I have just tried and I don;t need
CodeModification privilege. What I do is to send #evaluate to a String and
that seems to work without such a privilege.

I'll try to run an experimental run with the dynamic literals installing
> GLASS and Seaside and then give you a script when I get that working ...
>
>
>
Thanks Dale. I am still trying to understand where is the problem of having
the stack on a per user basis ;)

>
>
>> So..say I have just created the user 'glass' with the provided script. I
>> have loaded all GLASS and all my code in a SystemDictionary called 'GLASS'.
>> Cool, so far so good. So now I need to add this SystemDictionary into the
>> 'web' user. That seems fine as well. I guess a simple #at:put:.
>> I do understand I need to give write access to 'GLASS' to the web user.
>>
>> The write access is needed for Class Variables etc. If code is expecting
>> to stash some state in class variables, then you either share this state
>> between two users or you have to arrange for each user to have their own
>> slots in the Shared Code ...
>>
>> So if you don't use the trick of "per user class var associations" you
>> either load the code on a per user basis or edit the code so that class
>> variables, etc. are no longer used ...
>>
>>
> ok, got it.
>
>
>>
>> But I don't get why it would make sense to load seaside code into 'web'
>> uses space. You mean to load all 'GLASS' and all my code directly into the
>> web user instead than in 'glass' symbolList?
>> Of course, to do this I need to do it with the admin user ('glass' in
>> this example) because otherwise my web user doesn't have permission to load
>> code. if that is what you mean, then:
>>
>> 1) how can I load code into UserGlobals of user 'web' while I am
>> connected to topaz with 'glass' user ?
>>
>> My recommendation is that you use the "per user class var associations,
>> otherwise known as dynamic literal vars" and share the code.
>>
>> However if it turns out that you do need to load code on a per 'web' user
>> basis,
>>
>
> Ok, I want to start with this approach first.
>
>
>> you would use the trick of having the 'glass' user load the code into per
>> `web` user SymbolDictionaries ... each web user would get their own symbol
>> dictionary .... While doing the load, you'd have to monkey with the
>> UserSecurityData so that only the target `web` user has read/write access
>> (in the end SystemUser _might_ have to do the load) ...
>>
>
> mmmm how can I do that? I can create the 'glass' user (the user with
> 'CodeModification privilege) and I can create the 'web' user. But how do I
> load glass/myCode using the user 'glass' into a 'web' SymbolDictionary ?
>
>
>
>>
>> If you were writing code from scratch and knew that you were going to
>> partition the access permissions for data, you would avoid the direct
>> reference to class variables in your application code and it would be
>> simple to share code across multiple users .. The problem here is that
>> Seaside is not written to be "multi-user" and leverages the heck out of
>> "single-user" data structures like class vars, etc ...
>>
>
> Indeed, my app is neither prepared for "multi-user"....
>
>
>>
>> The "dynamic lieraral vars" trick was invented to allow a GLASS user to
>> leverage the shared code of open source packages while keeping the data
>> completely private ...
>>
>> 2) If I load glass and my code into the web user UserGlobal. Would the
>> DataCurator have access to it? I guess yes because that user is the one
>> that load it at the first time ;)
>>
>> Some user will have to have superior permissions ... and this user will
>> be the one responssible for system maintaince etc. ...
>>
>
> OK.
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140107/33a92ce0/attachment.html>