Dans l'architecture de données multi-locataires, quelle est la meilleure façon d'implémenter la vue de filtre des locataires?

Je suis en train de mettre en œuvre une application SaaS en utilisant ASP.Net MVC 2 et la base de données SQL Server. J'utilise l'approche Shared Tenancy.Dans l'architecture de données multi-locataires, quelle est la meilleure façon d'implémenter la vue de filtre des locataires?

Pour filtrer les données, jusqu'à présent j'ai trouvé 2 approches.

Option 1: http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tvf

utilisation d'une connexion sql par locataire. Ainsi, en utilisant SUSER_SID() en tant que filtre dans les vues

Option 2: http://blogs.imeta.co.uk/jyoung/archive/2010/03/22/845.aspx

stockage de l'ID de locataire dans le CONTEXT_INFO. Ainsi, en utilisant une fonction sql qui lit l'ID de locataire à partir de Context_Info comme un filtre dans les vues.

Pouvez-vous s'il vous plaît aidez-moi à choisir l'option appropriée?

Merci Merci

Source

2010-08-11 AlterWorld

Je pense que cela se résume à une bataille des modèles de sécurité. Un DBA peut vous demander de faire le premier. Étant plus pragmatique, je transmettrais probablement l'ID du locataire à mes SP ou à mes requêtes de la couche application. Je voudrais sauvegarder cela avec un tas de tests unitaires qui garantissent qu'un locataire ne peut jamais voir d'autres données de locataires, et je stockerais seulement le locataire actuel sur le serveur en session ou simmilar, jamais dans un cookie ou dans les URLs , ou n'importe où ailleurs qui peut être piraté sur le client.

Cela facilite beaucoup l'ajout de nouveaux locataires, car aucune configuration de base de données n'est requise.

Bien sûr, les séances peuvent être piraté, vous devez prendre toutes les précautions nécessaires pour faire en sorte que bon vous REF_MAGASIN locataire sur le serveur, il est à l'abri de parodies, etc.

Source

2010-08-11 16:19:27 RedFilter

Je suis avec vous sur celui-ci: l'option 1 n'est pas très flexible car elle repose sur l'hypothèse que chaque utilisateur existera au niveau du domaine. L'option 2 vous permet d'avoir des utilisateurs qui existent uniquement en tant que lignes dans une table utilisateur. Cela vous permet de remplir la table des utilisateurs en synchronisant avec l'AD du domaine de ce locataire. –

L'option de stocker l'identifiant de locataire dans la session n'était pas dans mon radar, alors pouvez-vous préciser comment l'implémenter? Je vais mapper l'URL du site locataire à un ID de client hébergé. Dans quel niveau, définissez-vous la session d'ID de locataire? Voulez-vous le stocker dans le cache de l'application? Merci – AlterWorld

Je pense à cela comme un site Web standard: l'utilisateur se connecte, vous prenez ensuite son ID de locataire et rediriger vers la page d'accueil de ces locataires. Bien qu'il soit correct d'utiliser l'ID de locataire dans l'URL, vous devez confirmer que l'utilisateur est * autorisé * pour accéder à ce tenanID à chaque requête, et un moyen simple de le faire est de garder le locataire en session ('Session [" TenantID "] = user.TenantID') afin que vous n'ayez pas à interroger la base de données pour le profil de l'utilisateur à chaque requête. Je mettrais probablement du code dans ma classe de contrôleur de base qui confirme que l'utilisateur est autorisé à accéder au TenantID dans la chaîne de requête; sinon, il redirige. – RedFilter

Je voudrais ajouter que table- en ligne Les fonctions valorisées peuvent également être utiles dans la construction de couches d'isolation.

Source

2010-08-11 17:29:50

Dans l'architecture de données multi-locataires, quelle est la meilleure façon d'implémenter la vue de filtre des locataires?

Répondre

Questions connexes