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

Dale K. Henrichs dale.henrichs at gemtalksystems.com
Tue Jan 7 11:15:52 PST 2014


----- Original Message -----

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

This also brings up the question of how are you going to give users the ability to customize their access to data. If you are planning to compile code then they will need code modification privileges ... 

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

| | | 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140107/2a358d9b/attachment-0001.html>


More information about the Glass mailing list