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

[Dale Henrichs]

On Tue, Jan 7, 2014 at 11:48 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

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

I'm sorry as well ... I'm afraid that I don't have a clear picture of what
you want to do ... I am under the impression that you don't want your web
user to be a clone of DataCurator, If so, then who do you think will be
doing the install and peridic updates of the code?

If you expect DataCurator to install the code then you _must_ use dynamic
literal variables to make it _possible_ for you user to store data into the
the class variables ... OR ... you must find all class var reference in the
installed code base and change the reference to UserGlobals ... the thing
about dynamic literal variables is that it does this mapping
"automatically" so by definition it is easier to use dynamic literal
variables than it is to edit code ...

If you don't expect DataCurator to the install and instead you give your
user all of the same privileges as DataCurator with a different name, then
everything is cool...

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

The permissions of the association for the class variables is established
at code install time by the user doing the install ... DataCurator can
install the same code into two different SymbolDictionaries, but since
DataCurator did the install, the privileges for the  code and Associations
are governed by the privileges in effect at the time of the install ... by
default everything will be owned by DataCurator ...

Moving a SymbolDictionary into another users SymbolList does not change the
privileges on the class var associations. So the user will not be able to
write to the associations ... they will be able to execute the code ... so
if you write code that does not use class variables or class instance
variables then you are in good shape ...

As I've said before Seaside is not written this way. With dynamic literal
variables it is possible arrange to make the class variable storage use the
current users UserGlobals (or any other object that the user has write
privileges for) and it is not necessary to modify the code ...



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

If it works it works (I didn't try it myself:) ... but this does explain
why you are going through all of this trouble in the first place:)

>
>
> 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 ;)
>

If you are going to have completely separate stacks for each user, then it
might make sense to go all of the way and have a separate stone for each
user ...

When you do a gemstone upgrade you are going to need to be able to
reinstall all of the source code of the application and if you have a
separate stack per user you are going to have to be able to reinstall and
updateand validate each user independently during the upgrade process ...
with separate stones you will be able to tackle each user/stone
independently ...

At this point with separate stacks per user, what is the advantage of using
a single stone?

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