You are not logged in.
Pages: 1
ATM I'm thinking about a Problem where i don't know exactly if mormot supports it or where i have to implement it.
I'm Starting with example Projekt 4 and add the Option to log in as different Users to the Client.
(Using : TSQLHttpClient(Form1.Database).SetUser('User','synopse');)
Now my wish is that every AuthUser has its own Data. I think adding a field UserID to SampleRecord would fullfill my needs.
Now my Problem / Question :
where on Server Side can i modify the Query to include "userid = authuser.id" ?
Rad Studio 12.1 Santorini
Offline
You are right, there are several possibilities.
You can use the TSQLAuthUser.Data field to store some blob.
But as you wrote, the best is to use a separate table, containing all data fields linked to a particular user.
Then, on the server, you can retrieve the current logged user from ServiceContext.Request.SessionUser.
Offline
Thank you Arnaud
can you please tell me which method to override where i can extend the select statement from the Clients ?
Rad Studio 12.1 Santorini
Offline
There is no method to override.
Just create a new table (inheriting from TSQLRecord), then add a reference to TSQLAuthUser via a dedicated field (or even forcing the ID at adding to match TSQLAuthUser.ID).
Offline
Hi, I guess you two are misunderstanding each other on this topic...
itSDS wants to write an application where all users share the same db (shema) but each user has its own restricted view on all tables in a way where each user can only see the data he has written. E.g. each user manages some projects and a timetable. Each user should only see his own projects and his own timetable. Therefore itSDS has asked for how to automatically append sth. like "userid = authuser.id" to all where clauses...
AB talked about adding additional data to a user record like a picture of the user or some other data. That could be in the TSQLAuthUser Table in the blob field data but like AB mentioned is better put in a different table and then associated with the TSQLAuthUser. Also one can create a table that inherits from TSQLAuthUser and has more specific additional fields.
If I am right with my assumption about what itSDS wants to achieve, IMHO that is application specific / domain specific and has nothing to do with the framework. However a hook that would allow to modify a query / where clause before the query get's executed could be useful in some hypothetic cases.
But I almost always would recommend to write a specific service that handles your applications needs instead of blowing up the core and walk away from the kiss principle.
Martin
Offline
Thanks Martin for the clarification.
An additional WHERE clause is in fact application specific, and could be achieved with the current state of the framework.
Using services instead of raw ORM would help a lot: the queries can be made on the server via services, but the client see high-level methods which returns only the table content matching its own user ID.
Another advice would be to define an INDEX on the field matching the ID.
You can use a parent class for all your TSQLRecord classes, which has this field. It would probably help writing and testing the code.
Offline
Pages: 1