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

[Dale K. Henrichs]

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

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

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

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

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

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

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