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

[Mariano Martinez Peck]

On Tue, Jan 7, 2014 at 9:03 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
>
> 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 think we are quite in sync in fact, just a little misunderstanding from
my part.


> 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?
>
>
Well...ideally ideally ideally, I wanted to have Seaside/Glass installed
many time, once per site. For each site I wanted to have 2 users, one
running the seaside gems with no privilege and one user with the code
modification privilege to make the load of the code, updates, etc. So Site1
will have 'webUser1' and 'adminUser2'. Site2 would have 'webUser2' and
'adminUser2'. Each 'webUserX' would be a normal user and each 'adminUserX'
would have the CodeModification privilege (or maybe the same as
DataCurator).
But this implied 2 main problems:
1) How do I load the code with a 'adminUserX' and share it ONLY with the
associated 'webUserX'.
2) The code loaded from the previous step should only be read/written by
those exact 2 users.

This was cool because I could run Seaside gems with some security out of
the box. But.... as a first step, I can manage to have only one user per
site, say 'adminUserX' and I use it for everything: load code, update code,
run seaside gems.

If you expect DataCurator
>

Yes I do. Not necessary DataCurator but a user with CodeModification
privilege.


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

OK. And this happens even if I don't user DataCurator but rather my own
'adminUserX' right? I mean, I would have the same problem if I want to use
'adminUserX' and 'webUserX', wouldn't I?


> ... 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...
>
>
Yes, this was the misunderstanding. I was thinking about this.....having
one 'adminUserX' per site (no 'webUserX') for all things will work without
problem.



> 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 ...
>
>
OK, I got it. But there is no way to change such privileges? I mean, if I
move the SymbolDictinary into another user SymbolList, cannot I change the
permissions so that the user can indeed write?


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

OK, I guess this is what I would need if I want to make it work with my
'adminUserX' and 'webUserX' right?
Is there a place I can read about these dynamic literal variables so that I
can know what should I do to make it work?


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

Indeed because if I would need CodeModification to evaluate a string I
could have used the same user for all.


>
>>
>> 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 ...
>
>
Indeed. That was the second step. I thought about this: first step,
multiple sites in the sense of separate GemStone users. Second step, not
only first step, but also multiple stones. But for second step I need to
dig more about how to create stones. So far I was happy with the seaside
one I get out of the box with the installGemstone.sh ;)


> 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 ...
>
>
That's a good point.


> At this point with separate stacks per user, what is the advantage of
> using a single stone?
>
>
Excellent question that I have been asking myself for a while. The thing is
that what I call a site may have only a few users (it could be from 1 to a
few or much more). It is like deploying the app for one particular client.
Maybe the client has 3 users, maybe 1, maybe 10, or maybe more. So I
thought that having one stone per site could be overkill. Is this the case?
Having multiple users in same stone allows me to group clients with a small
numbers of users. Does it make sense or your recommend to directly go with
a stone per site?

>
The problem with multiple sites within same stone is that I share the same
SPC. Having one stone per site solves this problem. But again, for small
clients this might not be a problem.

I am not sure yet if I would need to share data between clients. But in
this case, having multiple users within the same stone makes sharing data
easier, since I can use Published or something like that. If they are at
different stones, I need to serialize and manage the sharing myself.
Anyway, I would need this for the "second step" if case of needing sharing
data between sites...

Thanks Dale for your support!


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