[Glass] New user can't access GLASS & other classes

[Paul Baumann via Glass]

Jerry,

It has been several years since I've worked around issues like that, so
sorry if my recollection is fuzzy. You can share variables across different
users. It looks like segmenting and then permissions configuration are
missing. Be aware that the UserGlobals SymbolDictionary is (or perhaps was)
an Association-based collection and so reference the association instance
of a variable rather than the referencing the value.

If you somehow still have troubles then review which users get to update
the variable and perhaps store some data within your own data structure.
Though hard to explain all the code management advantages right now, a
strategy I found best was to have a shared application global that held a
singleton instance of an AppRoot kind of class. Application code would
reference the instance through the global by behavior, and instance
migration was useful to have. Practical implication is you only need to
solve this global sharing for one variable. Of course you can always use a
class instance variable to access by way of code like "AppRoot singleton".
The code then binds to a more customary class than a global variable. There
are several tricks that can be useful.

Background was that I wrote all the GemKit code management to manage
user-specific code and also to apply user-specific patches. Many good
tricks we're in that code base. Perhaps Montecello could borrow from tricks
that we're found in GemKit.

I understand that you'll be looking for the simplest workaround for GLASS,
and that several of the tricks mentioned above aren't customarily for your
refactoring. The association and permissions may be a good start. I recall
the GS manuals gave examples that accessed the association instances for
sharing between UserGlobals.

Hope this helps.

Paul Baumann
Retired young and loving it



On Mon, Jul 9, 2018, 4:27 PM Jerry Kott via Glass <
glass at lists.gemtalksystems.com> wrote:

> Some follow-up on the issue. I would like to extend my thanks to Richard
> Sargent who provided some useful tips in a private thread.
>
> It turns out that "GLASS is designed to store code in DataCurator's
> UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve
> tried several ways to get around it to be able to develop as a user other
> than DataCurator, unsuccessfully. Here are some of the things:
>
>
>    1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of
>    all the predefined groups to make sure group membership itself is not an
>    issue (in a real world scenario this would probably qualify as a bad
>    practice).
>    2. Then I did something that I was pretty sure was not going to be
>    kosher (I was right) and it wouldn’t work (I was partially wrong):
>
>    jkTestUser := AllUsers userWithId: 'JKTestUser’.
>    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
>    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
>    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s
>    UserGlobals”
>    System commitTransaction.
>
>    This allowed me to login as JKTestUser to a new session, and get the
>    same info in the testLogin window as the DataCurator session. However, when
>    I tried to do anything with the UserGlobals inserted into the test user
>    symbol list, I started getting security violations. This was kind of
>    expected as I didn’t think that sharing UserGlobals this way would be
>    appropriate anyway, for several reasons. I just wanted to see if it was
>    possible to bypass GS security by messing with the dictionaries this way.
>    Apparently not :)
>    I managed to get back the original UserGlobals into JKTestUser.
>
>    3. I did a couple of variations on the above, e.g., directly copy
>    classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of
>    the experiments would lead to a different kind of problems but security
>    violations seem to be the most common.
>
>    4. In my last experiment, I logged to my devKit stone with the topaz
>    command line tool as JKTestUser and tried to input a .tpz file that I found
>    GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals
>    would have its own class hierarchy for GLASS etc. That didn’t work either,
>    failed with compilation errors.
>
>
>
> I understand GsDevKit is more ‘community’ oriented with large parts of the
> code base ported from Pharo/Seaside, and not really part of the GemStone/S
> product, so naturally there will be some limitations and possibly friction
> points. This probably has something to do with Pharo/Seaside being
> essentially a single user system. However, I really dislike the idea of
> developing as DataCurator, so I am thinking that I would create some
> abstract classes and new ‘globals’ in the Published dictionary pointing to
> GLASS stuff. That might provide access to the things that I need as a
> ‘developer’ user. Naturally, the tricky part here will be to get a useable
> IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit
> of a chicken and egg situation.
>
> I wonder if others have similar experiences, or if people just use
> DataCurator as the default user when developing with GLASS. Or, if it is
> possible to bootstrap GLASS into a stone for a user other than DataCurator,
> what’s the trick?
>
> *Jerry Kott*
> This message has been digitally signed.
> PGP Fingerprint:
> A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5
>
>
>
> On 03-07-2018, at 10:28 PM, Jerry Kott <jkott at image-ware.com> wrote:
>
> Hello,
>
> this pertains to GsDevKit with GS 3.4.1.
>
> In a fresh client (tode1) I have created a new UserGroup (JKTestGroup),
> added a new UserProfile (JKTestUser) to it. Committed the transaction. I
> copied the content of my devKit_34 session profile and changed only the
> credentials. I have created a new client (tode2), in which I can see the
> two session profiles (devKit_34 and jkTest_34). I can log in to the stone
> (which is running on another host but that’s not a problem - I have ssh
> port forwarding set up and it works for both tode1 and tode2 clients). But
> when I do the ‘Test Login’ to jkTest_34 session, I get
>
> Stone            : !@localhost#server!devKit_34
> Stone host       : orion.local
> GemStone version : 3.4.1
> cpu kind         : x86_64
> GLASS not installed
> GLASS1 not installed
> Tode not installed
>
> whereas when I use the original devKit_34 session, I get the expected
>
> Stone            : !@localhost#server!devKit_34
> Stone host       : orion.local
> GemStone version : 3.4.1
> cpu kind         : x86_64
> GLASS version    : >=1.0-beta.9.2.1 [ConfigurationOfGLASS]
> Metacello version: >=1.0-beta.32.3 [ConfigurationOfMetacello]
> GLASS1:
>        repository: /gemstone/GsDevKit_home/shared/repos/glass/repository
> Tode:
>        repository: /gemstone/GsDevKit_home/shared/repos/tode/repository
>
> I have tracked this to the UserGlobals in the DataCurator user profile
> having all the GLASS & Tode classes. I’ve tried several different ways to
> put them into the JKTestUser symbol dictionaries (insert a new one, or put
> the classes in the Published dictionary), but when I do that, I get an
> error ‘improper store’ with some parameters.
>
> What should be a proper way to make the GLASS & Tode classes available to
> users other than DataCurator? Obviously I would like to do my development
> as a different user...
>
> *Jerry Kott*
> This message has been digitally signed.
> PGP Fingerprint:
> A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5
>
>
>
>
> _______________________________________________
> 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/20180709/597e1ed9/attachment.html>