M
mjacobs
Guest
The Client-Principal technology can work with your own built-in user account tables with no problems. In fact, that was its first use case. Your login scenario is correct. The choice of storage location can vary, and which one should be chosen base on your application's architecture. If you are writing stateful applications, especially in a web environment, there is always something that does back and forth between the client and the server. Because you are doing a login, I can assume the application architecture is stateful. So yes, the login operation would return to the client the session-id and pass it to the server on subsequent requests. The same process as is used in most web applications. When the request is received from the client you do a one-time operation: the session-id passed by the client is used as a key into the C-P storage and the C-P retrieved, followed by calling SET-DB-CLIENT() which will then tell you if the C-P is valid, expired, and do all the other internal settings. After SET-DB-CLIENT() successfully executed, all of your ABL code paths then execute in the context of that tenant without passing additional user information or code changes for new tenants. The user logout, or session expiration then removes the C-P from your storage location. The activate procedure is a good place to change user identities because it is a single location and satisfies the best practice that all security route through a single point before application code executes. In the later 11.x releases there is a 'client-context-id' that is generated and exchanged between OpenEdge clients and the AppServers, which is there to support server-side caching of Client-Principals. You use it like you would with a web browser and passing the http session-id back and forth. The later 11.x releases also allow you to pass the Client-Principal itself between OpenEdge clients and the AppServer - which supports the client-side caching of Client-Principals. Kind of like a web browser passing back and forth a cookie with the user's information in it. The 'client-context-id' is generally kept in sync with the C-P:session-id, which makes it easier to adapt to different clients. Yes, you call SET-EFFECTIVE-TENANT or SET-DB-CLIENT() one time at the start of each client request. The difference: SET-EFFECTIVE-TENANT provides no security and you have to do all of the user to tenant lookup yourself; SET-DB-CLIENT() is secure and does all of the user-id to tenant resolution for you. Again, your choice based on what requirements your application must meet.
Continue reading...
Continue reading...