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

James Foster james.foster at gemtalksystems.com
Wed Jan 8 07:53:13 PST 2014


Hi Mariano,

It does sound like you are on a reasonable path (and asking the right questions and getting the right answers). I recognize that refactoring code to eliminate the use of class variables is not trivial. Also, the desire to avoid commingling financial data is a strong argument for separate users or databases. 

My remaining concern is with letting users enter arbitrary Smalltalk code. It seems that using something like Petit Parser (http://seaside.gemtalksystems.com/ss/PortablePetitParser.html) might be preferable. Petit Parser will be part of the base class library in GemStone 3.2.

James

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

> 
> 
> 
> On Wed, Jan 8, 2014 at 11:17 AM, James Foster <james.foster at gemtalksystems.com> wrote:
> Mariano,
> 
> I’ve been following this conversation with interest and have a couple questions.
> 
> 
> Hi James,
>  
> 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.
> 
> My scenario is closer to a). In fact, for the moment the code that each site runs is exactly the same. The difference is in the database they use, and some setup that unfortunately is defined at class variables level... In the future, I might want to load certain package only to certain sites. Or maybe update one site to a kind of premium version with more packages or something like that. That's why I don't want to try to focus too much in the scenario in which I share the code for all sites. I prefer to have the code loaded for each site even if for the moment it is the same. Because this allows me to change/expand to further needs in the future, as I comment above. And moreover, I solve the problem of class variables. 
>  
> 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.
> 
> 
> OK good. Yes, that's the approach I was concluding: multi-user as a first step, and multi-stones as a second step. But Dale asked if that made sense...maybe I should jump direcly into a stone per site basis (second step). 
>  
> 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?
> 
> Yes to the latter...basically, the user can kind of define its own rules which is interpreted as Smalltalk code which is then evaluated. At the end, it is string which when evaluated it is a block closure, and then we do the #value. For that I am using String>>evaluate and #value. But this seems to work even without DataModification privilege!
>  
> 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.
> 
> 
> Totally agree. Yes, the "gemstone user" in my case is for the whole site. Real application users are managed by my own. I consider a GemStone user like it would be a relational db user. All this complexity I was thinking about ("admin" vs "web" user) was because right now I am not doing any validation in what the users can write as Smalltalk code. So I thought that directly making the seaside gem run under a user with no privilege would give me an security out of the box. But I have realized now (with all your help), that having these 2 types of users brings complexity. So maybe it is easier to use same user for everything (one with CodeModification privilege) and then write my own validations so that the user cannot type any arbitrary smalltalk expression. Or make a DSL or any kind of language that is then compiled to Smalltalk or something....like a rule engine. 
>  
> If the driving force for having multiple users for the multiple sites is to separate application data,
> 
> Good question. Yes, this was another of the reasons. 
>  
> 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.
> 
> Yes, I thought about this as well. This would solve the isolation of data, but I would still have the problem of class variables. I do use class variables that should apply only to "one instance of the app running". So to use this approach I would need to solve all these class variables. Which in fact, it makes sense. I would like to reify an "Application" object and move there all state specific for one app running. But I would like to let that for later.... (I need a working version asap ;) )
> 
>  Also, I know that from my app, the user will only have access to the correct application. But technically, from GemStone permission point of view, the user the gems are running *could* have access to the data of other site. So yes, we come back again to the fact that I should validate the expressions type by users etc.  In my case, the data is very critical since it is financial stuff. So I feel kind of a bit more safe if each site would be completely isolated from each other in terms of Gemstone itself (be it a different user or a different stone). 
> 
> Does it make sense?
> 
> 
> 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, your response is very appreciated. Sometimes this kind of answer is even better than answering what I asked ;)
>  
> 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
> 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

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


More information about the Glass mailing list