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

[James Foster]

Mariano,

I’ve been following this conversation with interest and have a couple questions.

First, I understand that you plan to run multiple sites. Do you expect to share code among the various sites? The two extremes are fairly simple: (a) all sites use the same code; and (b) there is no overlap in code use between the sites. In either of the extremes (or combinations of the extremes) it is easy to have the sites in the same database. If you want to be able to run one site with one version of some code and another site with another version of the same code then things start getting complicated. In that case multiple users or multiple databases is probably indicated.

Second, do you expect to allow your end-users to edit or create source code on the server or execute Smalltalk expressions that they write? The reason I ask is because you describe an interest in having an “admin” user and a “web” user. The UserProfile in GemStone/S dates from the Client/Server era when it was typical to have many users connect to the database using Smalltalk clients (VA/VW) where each user has an ID and password. Once they were connected they could do any operation for which their user had privileges. In the web-based thin-client era your users do not (typically) get a login user ID and password to the database (though they might get something equivalent to your application). All they can do is pass HTTP requests to a FastCGI adaptor (for example), and applications typically enforce their own security as part of the application code (instead of taking advantage of database features that enforce security when the various login users do not trust each other). If the only code that will run on the server is code that you write, then there is less need for the added complexity of separate users with different privileges.

If the driving force for having multiple users for the multiple sites is to separate application data, then I would also be inclined to consider an alternative that does not require multiple users. When code uses class (instance) variables to store application data, then the design tends to limit each class to supporting only one instance of the application. My preference is to have an Application class, where the instance(s) of the class hold the root objects of the application (typically a few collections). Then by selecting the desired Application instance early in the web request/response cycle, the rest of the code just interacts with the Application. There are various ways that can happen, but it is typically easier than multiple users.

I recognize that I’m guessing what problems you are trying to solve rather than answering your questions about how to use multiple users and enforce various types of security and privileges. So view this as more of my curiosity about what needs people have than as advice on how you should do things. 

Thanks,

James


On Jan 6, 2014, at 8:04 AM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:

> Hi guys. I am finding troubles to understand how should I organize my users and UserGlobals for my app. 
> 
> I want to have a user like DataCurator, let's say 'MyAppAdmin' that is allowed to create classes, update code, connect to GemTools, and other stuff. Then, I want a normal user (without any privilege) say 'MyAppWebUser' and the seaside gems of my app will be run with such a user.
> 
> So....how can I define these 2 users? I guess I can create a user and assign the DataCuratorGroup or policy. Is there anything specially recommended for this? (how to create a typical "admin" user)
> 
> Anyway... still..each of these users will have their own UserGlobals. If I load the code with 'MyAppAdmin' then it will be in the UserGlobals of that user and not available to 'MyAppWebUser'. What do I need to do? Put everything under Published list instead of UserGlobals?   So basically, I am asking how can I have an admin user and a none-admin both sharing the same UserGlobals (or similar).
> 
> Thanks in advance, 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

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