You are not logged in.
- Topics: Active | Unanswered
#1 2017-07-04 15:46:48
- keinn
- Member
- Registered: 2014-10-20
- Posts: 100
TSQLHttpClient.SessionUser does not contain the inherited detail .
i have my own AuthUser Table inherited from the TSQLAuthUser
TSQLMyAuthUser = class(TSQLAuthUser)
...
end;but ,
after success auth, the client TSQLHttpClient.SessionUser only get the TSQLAuthUser info .
i have to issue another query like TSQLMyAuthUser.Create to retreive the TSQLMyAuthUser detail ,
and to do this i have to grant every GROUP the R/W access rights to the TSQLMyAuthUser table( even if some group shoud not have this right).
i think it's a little wrong or waste of resource.
Last edited by keinn (2017-07-04 15:54:49)
Offline
#2 2017-07-04 19:00:28
Re: TSQLHttpClient.SessionUser does not contain the inherited detail .
ClientSetUser() create the TSQLMyAuthUser instance, and in fact, it retrieves the information not from the server, but from the ClientSetUser() parameters supplied on the client side.
If you want the full TSQLMyAuthUser information, just retrieve it explicitly from the server.
Read access is enough.
But in practice, what we do on client side is to not access the TSQLAuthUser information at all.
For security reasons, it is better kept on the server side only.
Then define an interface SOA service to access the expected information from the client side.
What we do in practice, is to have TSQLAuthUSer only for basic ORM access (and authentication), then put the user logic on a separated table.
Offline
#3 2017-07-05 01:14:12
- keinn
- Member
- Registered: 2014-10-20
- Posts: 100
Re: TSQLHttpClient.SessionUser does not contain the inherited detail .
thanks for the reply.
i have already put user logic on another table ~~~ just feel a little "coupled". may be the "data" field of TSQLAuthUser is better for store the user detail . but then we loose some search ability ,like "field index"
Offline