Results 1 to 7 of 7

Thread: Allow End User to manage own user access

  1. #1
    Senior Member
    Join Date
    Jul 2013
    Location
    Ontario, Canada
    Posts
    658

    Allow End User to manage own user access

    Hello,

    A while ago Barry posted the following information:
    http://www.lianja.com/community/show...nd-Permissions

    Has anyone attempted to make their own application so that end users can manage their own users and permissions?

    In the dynamic section, there is a section for app. Is this the app name, if so how would the end user know this information?
    How would we access the system user tables in our apps (main database is not stored locally)?

    If we continue to manage the users using the App Builder, how would we separate specific users associated with one business versus another business?

    Cory

  2. #2
    Lianja MVP
    Join Date
    Feb 2012
    Location
    Berea, KY, USA
    Posts
    2,187
    Hi Cory,

    this article http://www.lianja.com/doc/index.php/Users_and_Roles should answer most of your questions. If you forget the link, search for "dynamic roles" on the wiki (without the quotes). Take a look at the section of the document titled "Customizing Deployed Users and Roles".

    On the issue of users from multiple companies managed on the app builder: that's the subject of an ER already submitted (by me, which is the only way I'd know whether it had been submitted <s>). Assuming one has created an administration app, the real challenge is when you are testing a cloud app, and customers are hitting your test server to which you deploy a version for testing. Probably the best way to handle it (as contrasted with what I am doing now <s>) is to use the administration app you create to CRUD users and roles on the deployed version. It gets trickier with tenancies, but without tenancies you would only need the admin user to get into the app and handle users.

    hth,

    Hank

  3. #3
    Senior Member
    Join Date
    Jul 2013
    Location
    Ontario, Canada
    Posts
    658
    Hi Hank,

    Thanks for the response.
    I don't think I had seen that page yet.
    It does have a lot of useful information.

    Cory

  4. #4
    Lianja Development Team barrymavin's Avatar
    Join Date
    Feb 2012
    Location
    UK, USA, Thailand
    Posts
    7,193
    Blog Entries
    22
    Hi Hank,

    Users from multiple companies are handled already by specifying the "tenancy" as a "domain" in the user record in system!sysroles.

    When that user logs in the database they use is specific to their tenancy,

    Users are grouped into tenancies.

    Your ER (if i understand it correctly) is to handle multiple system databases so that the system database is specific to a tenancy. This is a catch 22 as you don't know the tenancy until the user has logged in.

    My assumption is that you want a system database specific to an app or group of apps. The ER has been submitted but I need to properly think it out and how this will work in Web/Mobile without being a security weakness.
    Last edited by barrymavin; 2015-04-25 at 01:41.
    Principal developer of Lianja, Recital and other products

    Follow me on:

    Twitter: http://twitter.com/lianjaInc
    Facebook: http://www.facebook.com/LianjaInc
    LinkedIn: http://www.linkedin.com/in/barrymavin

  5. #5
    Lianja MVP
    Join Date
    Feb 2012
    Location
    Berea, KY, USA
    Posts
    2,187
    Hi Barry,

    yes, it gets complicated. Even more so when using a web service, where the usual login isn't available, so that tenancy has to be held in a general system database, and then the database is switched on-the-fly. I save the tenancied-database in a session variable for subsequent calls. Save datasession would work, although not every table is used on every web service request, so there are fewer tables to reopen when doing it as needed (a prg that checks whether the db and alias are open, and open only if needed).

    The answer is, I believe, to create the user and dynamic roles apps and have that done by an admin for each app. That way everything is easy to manage. Only the admin_<thetenancy> user needs to be in the dev system, the rest gets done on the instance of the application. I'll likely be creating one for a consulting client, and if so, will add it to LianjaX.

    thanks,

    Hank

  6. #6
    Lianja Development Team barrymavin's Avatar
    Join Date
    Feb 2012
    Location
    UK, USA, Thailand
    Posts
    7,193
    Blog Entries
    22
    Hi Hank,

    As I mentioned earlier I will look into the best way to implement this when I make full tenancies available. Currently the system!sysroles table determines what database a certain user will use.

    Tenacies are more for regular apps than custom web services as these can be programmatically handled.
    Principal developer of Lianja, Recital and other products

    Follow me on:

    Twitter: http://twitter.com/lianjaInc
    Facebook: http://www.facebook.com/LianjaInc
    LinkedIn: http://www.linkedin.com/in/barrymavin

  7. #7
    Lianja MVP
    Join Date
    Feb 2012
    Location
    Berea, KY, USA
    Posts
    2,187
    Hi Barry,

    understood.

    In this case, the regular app is the manager for the web service. And on a given server, there would be <n> instances of the app. It all works out, in any case. The key is having an id for the source that matches up to a tenancy table in the default database (public), so the switch can be made. That makes sense from our perspective of managing multiple partners all using the same interface to their various POS systems.

    And I so think that the larger issue of managing users, even in a test environment, can be handled through a central system database. Separating users into one tenancy at a time can be handled by the UI. So, separate system db's probably aren't needed.

    thanks,

    Hank

Tags for this Thread

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Journey into the Cloud
Join us