[Answers] User

Printable View

2015-10-14, 04:29
josipradnik

[Answers] User

On the Windows desktop, user() returns the login from Windows, username() the name you use to login to the App Center or when you manually login to the App Builder.

When you install the Lianja App Builder, one user is already created - the 'admin' user, with the same password: 'admin'. You don't need to use these login details when you start the App Builder - you will be logged in automatically - but, you do need them to log into the Lianja App Center or when you log out of the App Builder Home Workspace and want to login again without exiting the App Builder.
When you Deploy, remember that you need to Deploy the system database along with your App, Data and Library scripts, so that your user and role data is available in the runtime environment.

If you want to handle this in code, you can control the visibility and updatability in the UI Presentation Rules.

http://www.lianja.com/community/atta...9&d=1422596845

Q:
control user access to certain command buttons on my Canvas page?
A:
You can use the UI presentation rules to "hide" or "disable" command buttons based on the UI presentation rules for "Visible when" and "Enabled when". These only take effect when you switch into runtime App view.
In order to maintain a consistent UI layout it may be better to disable specific buttons depending on who has logged in and what their roles are.
The userRoles() function can be used to get the roles of the logged in user then adjust the UI behavior accordingly in your custom section.

After careful consideration and considering the real need for database tenancies this has now been tied in properly with a users tenancy (domain) that is specified in the "Users" workspace.
This has been implemented as follows which fits in better with the overall architecture of the Lianja Platform.
Database tenancies are based on the authenticated user. The "Database" used by an App for a particular user in a specified tenancy is postfixed with an "_" followed by the tenancy (domain) for the user specified in the "Users" workspace.

For example, if the database for an App is southwind and the user has a tenacy (domain) specified of xyzco
then the database used for that user will be southwind_xyzco.
When the user authenticates in Desktop, Web or Mobile apps the specified database will be used rather than the default database for the App.

Remember to "Deploy" the system!sysroles table and the database for that tenancy from the "Deploy" workspace.

If a user who authenticates has no tenancy specified then they belong to the "public" tenancy.
You can think of a tenancy (domain) as a "company" or "organization".

This provides the ability to host a complete suite of Apps in the cloud or on a LAN with multi-company access but still maintaining security of the data across companies.
If you have hosted the Apps then you can of course consolidate information across multiple databases if you have that requirement.

We've had several developers asking how to run the same Apps against different databases depending on who the user is.
This is what "tenancies" are all about.
In order to simplify this I will be adding another field to the system!sysroles table called "database". When a user authenticates if this field in not empty then the specified database will be used rather than the default one that you have specified for the App.
This provides the ability to run the exact same Apps against different databases; e.g. one for each "company" that uses your App in the Cloud.

Q:
In our case, some clients has multiple companies in their group and the accessible companies within the group of companies depends on the user ID or user Role. BTW, am I correct that one user role can have multiple user IDs?
A:
Yes roles are whatever you want them to be then you can restrict access to apps, pages, sections and form items based on them.

Q:
we have been pondering the concept of "tenancies" for some time. Instead of having different databases can you place a Company Key against all Tables and have a single database?
The advantage would be gained (for us) when we need to sweep across the database for all clients to extract a common process file.
Currently, we use a key, but our legacy APP is in the LAN world and thus segregated anyway.
So the job would be to "sweep" through the multiple tenancies to accumulate the process file?
Or reverse engineer the procedure and have the tenancies spit the data out to a common process file?
A:
You would just need to open the databases and accumulate a process file.
use cust1!tablename
...
use cust2!tablename
...
etc
The database name can prefix the table name without having to explicit open the database.

Q:
How do you fit each tenant in that equation? i.e. tenancy1\cust1!tablename ... tenancy2\cust2!tablename
A:
A user currently belongs to a tenancy (domain in the users workspace).
I will be adding a "database" column to the system!sysroles table.
This will be used prior to the activation of full tenancies so that a user who authenticates works with tables in the specified database.

When full tenancies are enabled then all folders (including the data directory) are private to that tenancy.
So if you look at the current directory structure On windows under the lianja\cloudserver\public\ that is the default tenancy.
If a user has a tenancy of xyz.com then there will be a directory structure that is the domain of that tenancy:

Quote:

lianja\cloudserver\xyz.com\

which will include the "data" directory which in turn includes the databases for the xyz.com tenant.

This allows multiple tenants (or companies if you want to think of it like that) to be hosted on the same server or VM instance.
The "Runtime database" in the App Settings does that already. This is different, it for hosting different companies (tenants) running the same Apps against private databases.

When you setup users in Lianja you would normally assign "roles" to them that match the roles given in the UI Presentation rules for an App, Page, Section or field.
This fine granularity of permissions controls what CRUD (Create Read Update and Delete) operations can be performed by a given user on a UI element.

"Dynamic Roles and Permissions" can now be used to control this behavior without needing to have static roles specified (which still work as before). I have attached a screenshot to give you an idea about what this does.

Users are stored in the system!sysroles table and dynamic roles and permissions are stored in the system!sysperms table so you can write your own admin App to allow users with the correct permissions to setup their own users and roles. A dynamic role given to a user is prefixed with an @ character which causes the permissions to be looked up and applied to the UI at runtime.

http://www.lianja.com/community/atta...5&d=1410667347

Q:
How do I change the default user in App Builder? (Currently, it defaults to my Lianja username).
A:
The App Builder runs as your windows login and is treated as "admin". Why would you want to login as a different user? When developing you need all permissions.
Logins are primarily used in the App Center in conjunction with roles and permissions.

Q:
How do I create user login and password?
I inserted them into the User Tab
However, I still couldn't login through the app center.
A:
You need to deploy the "system" database.
You maintain it in dev mode and deploy it for runtime/web use.

Security is always an issue in web apps as i'm sure you understand, You can get the username in a server side procedure but not in the actual running client.

All topics in [Answers] alphabetically:http://www.lianja.com/community/show...ll=1#post12352
2016-03-02, 02:54
josipradnik

Q:
May I know the purpose of domain in user security setup?
A:
'Domain' is another name for 'Tenancy'.
"public" is the default tenant for a single customer installation.

the ui control is the same name you would use to reference a UI element using Lianja.getElementByID().
Dynamic roles can be created and/or edited from a custom admin App.
So in other words you can create dynamic roles which make sense in your application and when you add new users specify the name of a dynamic role.
For example, a typical use case is to setup an admin, supervisor, finance, manager role.

"public" is the default tenant for a single customer installation.

Q:
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?
A:
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.
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.

Q:
Is there any way to programmatically change the username and password of the users?
What I mean is that the users themselves will set there own username and password. Is that possible in lianja?
A:
Users and their permissions and tenancies etc are all stored in system!sysroles.
( example_registrationform app)

In Lianja v2.0.2 we've added support for user roles and permissions into web and mobile apps just as these work in desktop apps.

Permissions that are specified for apps, pages, sections, formitems and grid columns that are prefixed with a ~ e.g ~user negate the permission for a role. In other words if ~user was specified for the delete permission on an app then all authenticated users except those with the user role would have delete permission throughout the app unless explicitly enabled at the page or section level.

Q:
An ERP system would have many modules (apps) such as Inventory, Purchasing, Sales, etc. I have a system license key that determine what modules or apps will be enabled to the client users. May I know what App attribute can be used for this as I do not see a "Visible When" attribute in the App settings panel?
A:
When a user authenticates, their roles govern what apps they can see and what operations they can perform.

You specify roles for apps, pages, sections, fields and gadgets in the "Permissions" in the attributes.

If you specify a read role of xyz for an app and the user does not have xyz role they cannot see the app in the app center.

The app center does not integrate with third party licensing and we have no plan to do that work.

ISVs however can have licenses keys generated by us that have options specified which they can check at app load time. When you are in a position to deploy an application and require this functionality information on how to use it will be provided to you. There are undocumented functions that provide the ability to activate, deactivate, check and read various license information. This is included in the ISV subscription.

Q:
Let's say that I have 10 records in a table and I need that users in group A can see only records number 2, 3, 4 and 7 while users in group B can see only records number 1, 2, 5, 6, 8 and 10. Admin can see everything. What would be the best approach for this in Lianja?
A:
filter expressions can be macros such as {group_filter}

And you could declare group_filter as a global variable in the App "Ready" delegate based on who the logged in user is.

You can use the following functions to assist you. Look them up in the doc wiki for exact parameters needed.

userName( )
userRoles( )
userDomain( )
userEmail( )
userDatabase( )
userFullName( )

userRoles() returns a comma separated list of roles assigned to a user. You could see if the user has a specific role and if not restrict the records that are visible by them.

All topics in [Answers] alphabetically:http://www.lianja.com/community/show...ll=1#post12352
2017-02-06, 02:13
josipradnik

Lianja Users and Roles information is stored in the systemdatabase. Usernames and passwords are in the sysroles table.

Remember that the system database needs to be deployed for your Users and Roles to be used in the Lianja App Center and Lianja Cloud Server.

The sysroles table also includes the user's roles as well as their username and password. The USERROLES() function can be used to access the roles set.
Roles can apply to Apps, Pages, Sections and Fields. Depending on the level, the operations controlled include Admin, Create, Read, Update and Delete.

If you are sure that you need more information stored, then create an additional table - do not alter the structure of the existing system tables as these are used internally.

Once you have roles in the Web Client, when a user who does not have the role clicks the delete button on the actionbar, a message will be displayed to say that they cannot delete.
If you don't want them to see buttons that they cannot use, then yes with roles you will be able to set the Read role on individual Pages so that all users will be able to see certain pages and only users with specific roles will be able to see others.

Lianja does not have a built-in captcha control, but if you search online you should be able to find one - maybe css or JavaScript - that you can include.

Q:
I have created new user accounts with their corresponding roles.
At first log in the Lianja App Center fetches the correct user role. For example username 'mojeb' with role 'ADMINISTRATOR'. When I sign out the current user account and sign in again any account the user role becomes 'Admin'.

I signed in with username 'mojeb' and the role is 'ADMINISTRATOR'. When I access the database like query some records and signed out, when I sign in again using the same account the role becomes 'admin'.
But without accessing the database like I merely signed in and sign out right after, when I sign in again the same account the user role still the same.
I inserted new user account in system table with username 'mojeb' and role 'ADMINISTRATOR' and I've deleted the default user 'Admin' with role 'admin' and deployed it.
The problem here is that where does the app center got the use role 'admin' when it doesn't exist in system table?
A:
What role are you talking about is ADMINISTRATOR?
You can write a small app that when you login looks at the userRoles() and displays them.
Login with different users and display userRoles().

Any user who has no role specified or a role of * will have access to everything so they are assigned admin.
You restrict users by assigning roles to them.

You could have just as easily assigned user admin a new password.

Q:
I need to have two similar systems on the same server for 2 different companies, what can I do to separate them
because they occupy the same names and database applications, but independent information.
A:
That's what multi-tenant does for you, enabling you to run multiple companies all logging into the same app. The key is setting the Domain in the User information.
The system db has that information, so that also needs to be pushed to production.

The user's login directs the user to the right database, and Lianja internally handles the difference in database name.

Q:
We are testing a web app that uses the user's domain field to determine which database they access when they login along with their assigned role.
Rather than managing user passwords, is it possible to write a front end that enables users to login and authenticate with an external site, such as Google Sign-in or Facebook login, then upon successful authentication retrieve and match their userid/email address to their Lianja user record and automatically log them into Lianja?
A:
for logins associated with Google or Facebook, both provide a web api using OAuth2. You would, however, need to link the name of their Facebook or Google login and the Lianja user, beforehand. Once that is done you can:

a) allow guest login, but to a Landing Page, where they would authenticate through Google or Facebook. That would give you their login name for G+ or FB. You would then look them up in the Lianja users in order to set their database (and in future versions, the version of the app and the version of the Library).
The Sysroles table would be used to find the users permissions/tenancy.

b) implied in the above is a table of your own in which link the G+ or FB login with the Lianja domain + username.

Now, you can probably have users do the linking themselves: you would give the user a code that encrypts or points to an encrypted domain + username (which will have their roles attached).
From there depends on the actual factors at play in your context, but you can see the idea.

All topics in [Answers] alphabetically:http://www.lianja.com/community/showthread.php?2717-Answers
2018-01-24, 00:25
josipradnik

Lianja already supports user roles and permissions for UI elements and now in Lianja 3.4 user roles extend into the core of the database engine to provide row level security.
Row Level Security (RLS) is a concept that provides security at the row level within the database layer, instead of at the application layer. With this new feature you can implement RLS without changing your application code.

Row-Level Security enables customers to control access to rows in a database table based on the roles (or groups) of the user accessing data.
Row-Level Security (RLS) simplifies the design and coding of security in your application. RLS enables you to implement restrictions on data row access. For example ensuring that workers can access only those data rows that are pertinent to their department, or restricting a customer's data access to only the data relevant to their company.

Row level security in Lianja is accomplished using row filters. Each row filter is associated with a tenancy, database, table and role name.
When a user authenticates the tenancy and username determine the roles assigned to the user.
Whenever a database table is accessed, the database engine will lookup the row filters associated with the table based on the roles that the authenticated user has been assigned.

If a user has a specific role and a row filter exists for that named role then the row filter associated with that role is included (OR) from the records that can be read.
If the role name is negated e.g. ~manager and the user does not have manager role, then the row filter is excluded (AND NOT) from the records that can be read.
These row filters operate across native Lianja tables and virtual tables, so you can use them with MSSQL, MySQL, PostgreSQL and other third party SQL databases also.
When defining row filters for Virtual tables you should specify the name of the virtual table as the table e.g. vt_customers.
Row filters are transparent to the application in desktop, web and mobile apps as well as OData API calls. In other words no changes in your applications is required in order to benefit from row level security in Lianja.
You create row filters in the users workspace.

https://www.lianja.com/community/att...8&d=1487307869

Row filters are stored in the system!sysrowfilters table.
This table has the following table structure:

Quote:

Structure for table : sysrowfilters.dbf
Alias : sysrowfilters
Number of records : 2
Date of creation : 02/17/2017
Date of last update : 02/17/2017
DES3 Encrypted : No
CursorAdaptor : No
Field Field Name Type Width Dec Description
1 DOMAIN Character 80 Domain
2 DATABASE Character 80 Database
3 TABLE Character 80 Table
4 ROLE Character 80 Role
5 ROWFILTER Memo 8 RowFilter
** Total ** 329

Because row filters are stored in a database table you can also use standard SQL commands to perform CRUD operations on the row filters.
insert into system!sysrowfilters values ('public', 'southwind', 'customers', 'bname', [startsWith(customerid, 'B')])
Notice that 'public' is the tenancy that a authenticated user belongs to and 'bname' is the role you have assigned to the user. A user can have multiple roles.
If the role you specify is prefixed with a ~ e.g.
insert into system!sysrowfilters values ('public', 'southwind', 'customers', '~cname', [startsWith(customerid, 'C')])
and the authenticated user does not have the cname role, then all rows where the customerid starts with a C are excluded from what the user can see.
You can test data access for different users and roles using the following commands interactively in the console workspace.

Code:

open database southwind use customers list status list set rowfilter on | off set rowfilter to <expression>

The list status command now includes the roles and row filters for each table.

Q:
in a context of a multi company DB .. I can filter data for company?
Customers Table structure:
CompanyID, customerId, customerName
if the user is assigned to the comapany "A"
i can:

Code:

insert into system! sysrowfilters values ( 'public', 'Southwind', 'customers', '~ CompanyID' [= 'A'])

or

Code:

update ...

And the user see and edit only the Customers records where "CompanyId" = "A"?
In this way I can create a multi tenancy app in a easy way..

A:
Lianja already provides you with multi tenancy databases. You could use row filters but having a separate database for each company/tenant is a better choice in my opinion.
Row filters are better suited to providing views on data depending on user roles.
In your example code you would set the ROLE to 'companya' and the ROWFILTER to companyid='A'
Then you assign the companya role to users in that company.

Q:
Suppose we have many contract staff who join and go on different date. When I add these new users, how can I auto set it to an "expired role" (i.e. deny further login beyond expiry will prompt "Contract expired.") say 1 year or 1/2 year from the date of entry?

A:
The users table does not have an expiry date column. You could however add a role e.g. expires20170701 and have a background task running once a day that removes users who have expired. This could be a .rsp page.

A2:
I have added an "Expires" column into system!sysroles table in Lianja 3.5. If a user attempt to login and an expiry date has been specified then the login is rejected if it has matured.

All topics in [Answers] alphabetically: https://www.lianja.com/community/sho...ll=1#post13748

These answers are also systematized on the site "Lianja developer": https://lianjadeveloper.wordpress.co...ers-and-roles/