M
mjacobs
Guest
I would like to expand on Bill's response and offer another viewpoint: I would not recommend the SET-EFFECTIVE-TENANT or TENANT-WHERE use except in the case of a maintenance utility that is used to coordinate data between multiple tenants, which is what they were made for. These methods are simply unsafe because you lose the tenant isolation the database gives you, it bypasses any internal database auditing, it will not work well with table/field access permissions, and you have to be careful of audits (who generally do not like a client running code in the context of a privileged user who can access any tenant's data). Bill is correct that if you do not need secure multi-tenant support the SET-EFFECTIVE-TENANT could make your job easier. If you want/need a secure multi-tenant environment, the Client-Principal is more work but a better choice. The Client-Principal is simply a container (i.e token) of authenticated user information that the OE database connection can validate and subsequently use to coordinate setting the user-id, tenant-id, auditing user-id (and privileges), and database permissions in a single operation. It is relatively easy to generate, but the challenge lies in which application architecture use case you apply it to, because it can be used in a variety of them. You say your user logs into a stateless application, but where do you pick up the correct user-id for each request the client executes? Generally your application login code would generate the C-P and stores it in the some location where it can be easily referenced on subsequent requests. Your application probably already records the user-id for subsequent requests. Once a request starts you retrieve who the user is, their C-P, and use SET-DB-CLIENT(hCP). How the stateless request knows which authenticated user it is (and therefore their C-P) can be done in a variety of ways, but the starting point is to look into leveraging what your application already does. The Client-Principal is also a means of passing user identity from one OpenEdge component (such as an AppServer to AppServer) in the 11.x releases so that you use the same user identity consistently in multiple places. Just in case this is in your future. I hope this helps you decide which is the best path to take for your application.
Continue reading...
Continue reading...