Few questions and/or feature requests

AOG · 2015-03-23 10:46:14

Hello Ab,

1) User access.
In a few of my applications, I have tables with rows that can be identified not only by their own ID, but also by their UserID. This UserID is a copy of the users own User ID. E.g users own rows in a table. Admins own the whole table.
As an example: think of project hour registration in a single table: a user may only see his own hours.
Normally, one would disallow access to this table by setting permissions, and subsequently use a method to access row data.
But I am now encountering this very frequently in my applications. Many tables with rows that are owned by users: many methods to control access.
Question/feature:
Would it be possible/feasible to add the possibility for an optional row-owner to the whole mORMot framework ?
E.g. add a colums with a distinct name: OwnerID, that can be filled (auto-magically) with the UserID ?

Edit:
while preventing access to tables, am I correct in my conclusion that Admins always have access, even if this is disallowed by setting SQLAccessRights to false for a particular table ?
Edit2: my mistake: access is prevented, even for Admins !

2) Backup/restore.
Being in the process of designing applications, I encouter many feature requests by my users.
Some of these require changes in the model.
But the database is already in use. So existing data must be re-used.
Question/feature:
It would be nice to be able to backup the whole model (I mean data, not structure) as JSON.
And to import it again in the (changed) model. Auto-magically.
If I look at the database and mORMot source, I see only one problem (but correct me if I am wrong): the AccessRights inside TSQLAuthGroup.
These AccessRights must be exported as plain table names, and imported and converted again into the right table-numbers for the changed model.
The above will not work for all cases, but it would help a lot.
At the moment, I am using manual JSON table backup and restore.

Thanks in andvance, Alfred.

Last edited by AOG (2015-03-23 11:54:37)

ab · 2015-03-23 13:39:30

1) IMHO this sounds more like business logic than REST logic.
There is no notion "user" in REST (which is stateless), whereas there is a notion of "resource" in REST, which matches our Table concept in the ORM.

So it did make sense to add authorization at table level for REST level.
It may also make sense to add authorization for a row level (i.e. for a particular REST ID) - even if it would need a list of all allowed IDs, which is difficult to maintain for huge table. So perhaps not worth it.
But it did not make sense to add an "user" authorization level at REST level.

What may be feasible could be to add a new TSQLRestSever.OnReadEvent() callback, similar to OnUpdateEvent, which may be checked when a data row is retrieved, allow to return a HTML_NOTALLOWED error.
But the TSQLRecord object is still JSON at this level, so the event may have to unserialize it into a TSQLRecord instance to check for a particular condition (e.g. a UserID field).
You could add a feature request ticket for this (with a link to this forum thread).

2) If you change the Model, you should not change the table name.
Otherwise, TSQLAuthGroup table bits would change, but also any RecordReference published properties.

Note that faster backup would involve using SQLite3 backup features.

AOG · 2015-03-23 15:37:55

Ok ! Thanks for your answer.

I would welcome a OnReadEvent() callback.

If I understand correctly, I would need to decode the singe UserID field from JSON inside this callback and do something like Accept:=(SessionUser=Table.UserID) ?
As you can see, I am proposing an Accept flag for each row received, if this event is assigned.

ab · 2015-03-23 16:35:26

Yes, but OnReadEvent() would work only for individual GET requests, not a list.

This is why IMHO a dedicated SOA service is better.

AOG · 2015-03-25 07:29:51

Allright. For row-access, I will stick to methods. The OnReadEvent will be very expensive in terms of processor-cycles.

However, I would like to ask your opinion on another access problem: field access.
Again, sometimes field access must be limited.
E.g. employee-salary may only be visible to bosses and oneself, but employee-email to everybody.

And again, this can be done with methods.

But perhaps also by mORMot.
I was thinking of something like this:

 TSQLMyRecord = class(TSQLRecordPeople)
  protected
    fSalary: double;
    fEmail: RAwUTF8;
  published
    property Salary: double read fSalery write fSalery index (LIMIT_ACCESS OR ADMINGROUP OR ONESELF) ;
    property Email: RawUTF8 read fEmail write fEmail;
  end;

LIMIT_ACCESS=$10000;
ADMINGROUP=$001;// e.g. groupindex from AuthGroup or something else to limit access
ONESELF=$100;

Sure, field-access can be handled on the client-side, but it would perhaps be much better handled on server (ORM) side.
Limiting rest-access also on field-level. So all rest-client share the same access (security) limits.

Methods can handle all this, but I am curious to hear other ideas about mORMot-field-security.
Thanks.

edit:

Perhaps adding a function like this:

  G:=TSQLAuthGroup.Create(Self,'Ident = ?',['User']);
  if G.ID>0 then
  begin
    A:=G.SQLAccessRights;
    A.Edit(Self.Model,TSQLEmployee,false,false,false,false);
    // field level CRUD access
    A.Edit(Self.Model,TSQLEmployee,'Salery',AuthGroupID,true,true,true,false);
    A.Edit(Self.Model,TSQLEmployee,'Salery',AuthGroupID,false,false,false,false);

Last edited by AOG (2015-03-25 07:56:45)

ab · 2015-03-25 08:36:42

IMHO this would benefit to be at application level, not at REST/ORM level.

With a SOA approach, you can modularize the returned information as expected, much better than with options like those...

mORMot Open Source

#1 2015-03-23 10:46:14

Few questions and/or feature requests

#2 2015-03-23 13:39:30

Re: Few questions and/or feature requests

#3 2015-03-23 15:37:55

Re: Few questions and/or feature requests

#4 2015-03-23 16:35:26

Re: Few questions and/or feature requests

#5 2015-03-25 07:29:51

Re: Few questions and/or feature requests

#6 2015-03-25 08:36:42

Re: Few questions and/or feature requests

Board footer