Best way to segregate data

I had a look at the Saas sample, and the basis of segregation is very similar what I have in mind for my project. I want users to have their own accounts, with data and historic data only relevant to them.

I know I could use the datasources as discussed in my other posted question, but I also noticed this Saas uses roles which you need to define outside the actual app source code, and it works well. I’m just curious which is the best way of doing so.

Also, is the user and other administrative windows blackboxed in the java binaries? Is there a way to override them to be used in the main application instead?

Hi Ben,

in the SaaS example the user groups are relevant for filtering the data depending on the current user (or current customer in this case) - or did i get your wrong on that? The main difference is that the security constrains are applied to datasource queries in a transparent way for the application developer. This is a big benefit, because security does not become a problem of the application developer anymore. It can’t be forgotten to implement and at the same time it is much more flexible…

On the other hand, just creating security constraints at runtime might be a little bit too flexible. Therefore, in the SaaS example there is some part baked into the source code (especially the init method in the StandardClientEntity which tries to set the client id and throws an exception if running in a non-client scenario.

For your other question regarding blackboxes: Yes you can extend and change the different behaviors of the different parts of the platform. You can start your journey here: Functionality Extension - CUBA Platform. Developer’s Manual. In the example the user gets an additional attribute: “address”.
But i would argue, that you should think about creating another entity that holds the application data for the user (like Customer) and attach a user account to it. But that obviously depends on your requirements.


Hi Mario,

First of, I honestly didn’t expect an answer over the weekend, thank you for taking some time on this.

I were just looking from a security perspective what users of this platform think is the best way. I saw the StandardClientEntity and the init and exception. At first I couldn’t find the filters then I found it in Administration area within the app itself, so it made sense how it was done first. I don’t dislike it, dynamic queries is something I enjoy due to the flexibility, but I always monitor overhead and the SQL explain plan to make sure it doesn’t break under load. I worked on realtime transactions before and I just have a habit of planning for overhead :slight_smile: But since this is not a realtime solution I work on this might not be something I should be too concerned about.

As for what I want to do :

  1. Admin user which sees all (The basic OOTB system after generated)
  2. Anonynous users can register, and are inserted as “users” in the database. So they fill in a scaled down user form (Not the full one, thus my question where it is kept)
  3. The users have their own dashboard (Was originally thinking Portal, but I think I could get away with the app itself since I want to use the premium addons after I buy it to allow nice charts for the end users)
  4. Comment section (Pseudo forum like style) where users can comment and look at others feeds (Very simplistic)

That is basically it in a nutshell. I am linking into two major systems (Salesforce etc), and that code I will integrate later on. Thus the account segregation questions.

Hi Ben,

I always monitor overhead and the SQL explain plan to make sure it doesn’t break under load

Your concern is very valid, and you should check what SQL is finally executed for all access groups and entities, prior to going to production.

Anonynous users can register, and are inserted as “users” in the database.

This is quite a common task, so we’ll create an example of anonymous access and self-registration.

As for extending platform entities and screens, see also this example: GitHub - cuba-platform/sample-extensions: Extending entities and screens