避免在会话中为不同的SQL模式存储连接字符串 [英] Avoid storing connection string in session for different sql schema

问题描述

我计划在Azure中创建一个多租户应用程序，该应用程序通过架构分离实现数据隔离.

I am planning to have a multi tenant application in Azure where data isolation is achieved via schema separation.

我计划使用子域来标识租户.想法是从子域中获取租户名称，从登录页面中获取用户ID和密码，并验证uid，pwd&身份验证的租户ID.如果通过身份验证，则需要将应用程序对SPROCS的所有调用都定向到架构(与承租人相同的名称).

I am planning to use subdomain to identify the tenant. Idea is to get the tenant name from the sub-domain, get the user-id and password from the login page and validate the uid, pwd & tenant id for the authentication. If authenticated, all the calls to SPROCS from the application needs to be directed to the schema (same name as the tenant).

但是，我不想将租户明智的连接字符串存储在web.config文件中.我能想到的一种选择是，将架构名称和密码存储在登录页面可接受的表中，并创建租户特定的连接字符串(及其UID和密码)并将其存储在会话中.初始化任何存储过程时，请使用此连接字符串.

However, i dont want to store tenant wise connection string in the web.config file. 1 option i can think of is, store the schema name and password in a table that is acceptable from the login page, and create the tenant specific connection string (with its UID and Password) and store it in session. Use this connection string while initializing any Stored Procedure.

但是，我不希望在会话中存储模式的uid和密码.还有其他方法可以管理这种情况吗?

However, i am not keen on storing uid and password of the schema in session. Is there any other way to manage this scenario?

推荐答案

在会话中存储连接字符串不会对安全造成危害，因为会话值未存储在Cookie中. Cookie中只会存储会话ID，会话的每个值都与会话ID一起存储在服务器中.

There is no security harm to store connection string in session, as session values are not stored in Cookie. Only Session ID will be stored in cookie, and each values of session stored in server along with the Session ID.

但是，连接字符串对于访问应用程序的用户组(在您的租户中)是通用的.因此，在会话中存储将使用更多的内存.始终尝试使用上下文方法，例如，您的数据层代码将按如下方式引用连接字符串

But the connection string is common for group of users who access the application, in your case tenant. So storing in session will use more memory. Always try to use Context Approach, for example your Data Layer code will refer connection string as follows

String con = AppContext.Current.ConnectionString;

String con=AppContext.Current.ConnectionString;

AppContext类上方将具有实际的逻辑，以根据主机的类型(例如工作人员角色，Web角色，单元测试等)检索连接字符串.

Above AppContext class will have actual logic to retrieve the connection string based on type of the host, such as worker role, web role, unit test etc..

•您可以将连接字符串存储在web.config中，并且密钥可以以子域值作为前缀 示例:Subdomain1_connection =连接字符串

•You can store the connection string in web.config, and key can be prefixed with sub domain value Example: Subdomain1_connection =connection string

•如果您有存储所有租户信息的中央数据库，则可以将它们存储在数据库中

•You can store them in a data base if you have central DB where all the tenants information stored

•如果没有这样的数据库，则可以创建Azure表来存储租户信息

•If you don’t have such DB, you can create Azure table to store tenant information

在任何多租户应用程序中，我始终都有两个上下文变量，即AppContext和UserContext，这两个上下文提供了适当的数据.因此，我的单元测试不必担心会话，上下文将根据应用程序的运行位置从静态字典或会话或数据库或Azure表中传递值.

I always have two context variables in any multi-tenant application, AppContext and UserContext, this two contexts provides appropriate data. So my unit test don’t bother about sessions, the context will deliver the values from static dictionary OR session OR database OR Azure table based on where my app is running.

这篇关于避免在会话中为不同的SQL模式存储连接字符串的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！