February 2, 2010 at 6:57 am
Greetings.
We are migrating gradually from FoxPro databases and applications to SQL Server databases and .NET applications. Applications are built in-house, some will remain fat client while others will switch to web-like (intranet) apps with individual pages. We are working through developing the security model for this. This is our general plan, at present:
A couple of Windows domain groups into which SQL Server users would belong, basically "low-level" and "high-level" users. SQL Server access would be via stored procedures only (and probably some views), but not to any tables directly. An Application Manager program, serving as a developer interface, listing all in-house-developed applications, associated privileges, and the ability to specify them per user. When an application starts up, it queries to obtain the specific application privileges for that user, determing which application components (and resulting SQL Server stored procedure calls) are available to that user. An application key, also loaded upon startup, and passed along with the SQL Server stored procedure calls, to prevent accessing the stored procedures by tools external to the application.
This all works in testing just fine for fat-client type applications. It seems clumsy for web-type page-driven (stateless) applications. For those, for each page, it must first query to obtain the user's access privileges and the application key. This is an extra hit to SQL Server for each page. Is there a recommended way to retain user-specific privilege settings on the client (encrypted cookies?) to avoid this seemingly unnecessary hit every page, or is there a recommended alternative, etc.?
Thanks,
Randy
February 2, 2010 at 8:19 am
Sessions or Cache might work for you in this case. You could look at Third Party caching tools like memcache as well.
-Roy
Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply