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

Wed Jan 8 07:14:59 PST 2014

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/0b149f59/attachment-0001.html>