mORMot Open Source

birger

Member

From: Delft

Registered: 2013-04-11

Posts: 2

Website

Subclass TSQLAuthUser

I am working on a project with multiple users that should be grouped wheb they belong to the same company. This so that users from the same company can see each others data. Also I want to add some preferences data (language, timezone etc).

Is it wise to create a new class based on TSQLAuthUser and add the required properties or should I try to put everything in the .Data property?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Re: Subclass TSQLAuthUser

I suspect the better may be to create a dedicated class inheriting from TSQLAuthUser.

But the framework does not allow to use directly a sub-class of TSQLAuthUser, only plain TSQLAuthUser class.

Worth a ticket as a feature request, I suspect.
http://synopse.info/fossil/reportlist

In the meanwhile, the .Data property may be the way to go.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Re: Subclass TSQLAuthUser

That's it!

You can now define in the Model your custom TSQLAuthUser and/or TSQLAuthGroup classes to store the authorization information: TSQLRestServer will search for any table inheriting from TSQLAuthUser/TSQLAuthGroup in the TSQLModel - see also corresponding TSQLRestServer.SQLAuthUserClass/SQLAuthGroupClass new properties.

See http://synopse.info/fossil/tkttimeline/5a17a4277f?y=ci

jaclas

Member

Registered: 2014-09-12

Posts: 215

Re: Subclass TSQLAuthUser

Hello,

You wrote in docs:

"The Server will search for any class inheriting from TSQLAuthGroup and TSQLAuthUser in its Model. By
default, you can use plain TSQLAuthGroup and TSQLAuthUser classes - and if none is defined in the
model, and authentication is enabled, those mandatory classes will be added. But you can inherit from
TSQLAuthGroup and TSQLAuthUser, and define e.g. your own fields, for any custom purpose at Group
or User level."

TSQLAuthUser class contains published properties:
   LogonName property: RawUTF8
   DisplayName property: RawUTF8
   PasswordHashHexa property: RawUTF8
   GroupRights property: TSQLAuthGroup
   Date: TSQLRawBlob

If I want to have my own table with users I should inherit from TSQLAuthUser, but it will make the original field will be in my class. Is it possible to delete these fields from the model?
I would like to my TMySQLAuthUser class had only those fields which I'll define.

--
best regards

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Re: Subclass TSQLAuthUser

Those fields are needed by the authentication processes included in the framework.
So they are mandatory (with the exception of Data perhaps).
This is how inheritance work.

Ensure that you are not mixing application data and authentication data.
It is not a problem to have two tables for users: one for the authentication, and another for your application.
You can just let your application maintain a synch between the two tables.
IMHO this is the cleanest way.