¿Utiliza la base de datos de proveedores de membresía de ASP.NET con su propia base de datos?

Question

estamos desarrollando un ASP.NET MVC aplicación que en la actualidad se utiliza de base de datos propia ApplicationData para los modelos de dominio y otra Membership para el proveedor de gestión de usuario/membresía.

Hacemos restricciones de acceso usando data-annotations en nuestros controladores.

[Authorize(Roles = "administrators, managers")] 

Esto funcionó muy bien para casos de uso simple.

---

Como estamos intensificando nuestra solicitud de nuestro cliente quiere restringir specific users acceder a áreas específicas de nuestra base de datos ApplicationData.

Cada uno de nuestros productos contiene una clave externa se refiere a la región en el que se ensambla en

Una historia de usuario sería:.

• Los usuarios de los NewYorkManagers papel sólo deben ser capaces de editar/ver productos que se ensamblan en Nueva York.

Hemos creado una tabla de marcador de posición UserRightsRegions que contiene el UserId y la RegionId.

¿Cómo puedo enlace tanto el ApplicationData y los Membership bases de datos con el fin de funcionar correctamente/cross-database-key-references tener? (Es algo como esto incluso posible?)

Toda la ayuda es más apreciado!

Answer 1

En mi opinión, debería ser capaz de integrar su base de datos con la aspnet_db estándar fiable, pero yo aconsejaría contra la duplicación o la sustitución de la tabla aspnet_users.

Ese es el punto focal de todos los proveedores que usan el esquema aspnet_db, incluidos los proveedores personalizados que pueden aumentar pero no implementar el reemplazo personalizado.

Para maximizar la reutilización del código de infraestructura probado en la pila/API del proveedor, es mejor seguir ese flujo.

Querrá estar muy atento a las funciones básicas de la membresía modificada y asegurarse de que la forma en que se comportan sus nuevas restricciones sea la esperada en cada caso.

La faceta de la historia de membresía que he encontrado necesita la mayor atención es la eliminación de un usuario, y una simple modificación/adición a la eliminación del usuario sproc puede manejar esto hábilmente.

Answer 2

Parece que podría necesitar crear su propio proveedor de membresía personalizado. Probablemente (no positivo aquí) amplíes el existente para que no tengas que reinventarlo por completo. Here es un video de ASP.net que describe cómo hacerlo. Google "proveedor de membresía asp.net" por toneladas más.

Answer 3

Puede intentar obtener su propia membresía o simplemente extenderla como sugiere Dave.

Cree su propia tabla [Users] que se puede llenar en función de la tabla aspnet_Membership. Por lo tanto, podría tener más control sobre eso.

También podría implementar un sistema de perfiles más complicado. El equipo .NET ha mejorado la manera en que se almacenan los perfiles ahora, así que en lugar de "blobizarlos", puedes configurarlos para que se almacenen en una tabla real ahora [gracias a Dios].

Table Profile Provider

Answer 4

Si encuentra los artículos adecuados, es muy fácil ampliar el proveedor de membresía para permitir una funcionalidad adicional. He movido mi tabla de usuarios a la tabla principal de mi servidor SQL y he escrito mi propio administrador de roles que obtiene los valores de una tabla separada. Lo que parece que debe hacer es configurar una tabla en su base de datos de usuarios con la ubicación de cada usuario, luego cree un método en el objeto del usuario algo así como "GetLocation()" que devuelva la ubicación del usuario del DB, usted podría entonces usar eso para filtrar sus datos desde su base de datos principal. Aquí hay algunos artículos que tuve en mis marcadores, ver si me ayudan, si echas un vistazo al sitio principal de ASP.NET o google para los artículos que extienden los miembros del proveedor de membresía, hay mucho por ahí. http://msdn.microsoft.com/en-us/library/ms998347.aspx http://www.4guysfromrolla.com/articles/120705-1.aspx http://msdn.microsoft.com/en-us/library/aa479048.aspx

Answer 5

Como los otros han señalado que hay muchos buenos recursos disponibles que pueden ayudar con la creación de su proveedor personalizado utilizando la base de datos existente.

Parece que va en la dirección correcta con tablas de asignación. Creo que la única pieza que te falta es Distributed Queries. Este enlace es específico de Sql Server 2008. Existe un enlace a la documentación para Sql Server 2005 si eso es lo que está utilizando.