Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Help needed concerning the configuration for different user groups

    Hello,

    I would appriciate if someone would give me some hints how to structure/configure my application.

    Currently, the application runs for a single user group. There is one html-file, one gwt.xml-file, one css-file, one set of datasource-xml-files.
    Now, the application shall be used by several user groups. They shall get their own html-file (for startup) and their own css-files, but all the other files (datasource definitions, client- and server-files) shall be used independently of the user groups.

    What do I have to change?

    Thank you
    Andreas


    #2
    Hello,

    I am thinking of the following:
    for each user-group separate html- and css-files are placed in a subfolder of the webapp directory, the html-files refer the sc-files (existing once) and especially the datasource-xml-files.
    A user-group identification is placed as an attribute of the javascript-var window and is read by the client.
    A criteria of a clinet's request will get an additional attribute 'usergroup' that is set to this value. This will allow the server to refer to different databases.

    Will that work (esp. the last part, the first part works)?

    Thank you
    Andreas

    Comment


      #3
      Hi Andreas,

      "A criteria of a clinet's request will get an additional attribute 'usergroup' that is set to this value. This will allow the server to refer to different databases."
      is a bad idea IMHO (never trust the client). Why do you need this at all? You can differentiate between usergroups very easy with the grants the server gets for the user after login from the DB.
      With this you can build a very fine grained role based or even capability based system. Role based sounds like what you need.

      In your onModuleLoad check to which group the user belongs and load the appropriate UI. Besides the fact that all user groups share the same big(ger) *.cache.js, this approach has only advantages IMHO.

      Best regards
      Blama

      Comment


        #4
        Hi,

        Each user group (at different locations) has its own database which includes some authorization data.
        I will think about your suggestion to separate authorization requests and regular requests.

        Thank you
        Andreas

        Comment


          #5
          Hi AHagerer,

          please see DynamicDSGenerator, which allows you to customize your .ds.xml on arbitrary criteria like your usergroup. You could modify dbName, making the framework use different credentials per usergroup.

          Best regards
          Blama

          Comment


            #6
            I have a similar system, which is role-based. In a nutshell, this is how it works:

            CLIENT-SIDE:
            In my entrypoint (onModuleLoad), i start with fetching various user-related account parameters from the server (name, role, isbeta, showwelcomewindow, etc.)

            Our application is tabbed, so i have coded a bunch of "ComponentCreator" classes that put together different components based on the role. For example, i have a 'AdminComponentCreator' that have more tabs than the "UserComponentCreator" classes. In my entrypoint, i choose the componentcreator based on the role.

            Various forms and layouts also look different depending on the role, but there i mostly show and/or hide fields and widgets based on the role. For example, certain fields are only editable for admins. In other places, i show different buttons based on the role, but this kind of stuff is mostly directly in the code, since it's specific to that component. A user could hack this and switch role in the browser, but since server-side operators are controlled by role-based security (see below), it won't matter much. Also, only paying customers use this site.

            SERVER-SIDE
            i use spring and spring-security for data access
            I mostly have the same datasources, since it's usually not a security issue that certain fields that are only shown for admins still gets sent to the client.
            I have it in a couple of places though, and there i have different datasources based on the role, and insert the "right" datasource in, for example a listgrid, based on the role. In those cases, i of course have different server-side methods too, so that i can restrict access only to the roles that are allowed to fetch that data.
            Same thing with CRUD operations, i have role-based field access so that each role will only update fields allowed by the role.

            DATABASE
            I only have one schema, as mentioned access to it is controlled by service classes based on the role for the authenticated user. This is the same access rules i have for the smartgwt web services as well as my rest services and my SMS interfaces etc.

            Hope it's at least somewhat helpful, happy to comment more.

            EDIT: as you can see, i agree wih Blama. Never trust the client.

            Comment

            Working...
            X