Comment faire pour qu'un utilisateur voit une table différente avec le même nom

Question

Objectif: Lorsque tout le monde sélectionne SELECT * FROM mytable, il voit une version de la table. Mais lorsqu'un utilisateur spécifique sélectionne SELECT * FROM mytable, il voit une autre version de la table.

Je pense que je suis à mi-chemin avec la création d'un nouveau rôle et la mise en place de l'utilisateur unique. Puis en créant une copie de la table par défaut avec SELECT * INTO newrole.mytable FROM dbo.mytable. Mais lorsque l'utilisateur sélectionne SELECT * FROM mytable, il voit toujours le fichier dbo.mytable. Comment puis-je les faire passer par défaut à newrole.mytable? J'ai encore besoin d'eux pour voir toutes les autres tables dbo juste pas celle-ci.

Answer 1

Créez un nouveau schéma, et une table en double (ou une vue sur dbo.table si c'est ce que vous voulez) - par exemple, otheruser.table. Ensuite, définissez la connexion de l'utilisateur par défaut à ce schéma:

USE atest 
GO 

CREATE ROLE [arole] 
GO 

CREATE SCHEMA [aschema] AUTHORIZATION [arole] 
GO 

CREATE USER [auser] FOR LOGIN [modify_user] WITH DEFAULT_SCHEMA = aschema 
GO 

EXEC sp_addrolemember 'arole', 'auser' 
GO 

CREATE TABLE dbo.atable (col1 int) 
GO 

CREATE TABLE aschema.atable (col2 varchar(10)) 
GO 

INSERT INTO dbo.atable(col1) VALUES(1) 
GO 

INSERT INTO aschema.atable(col2) VALUES('One') 
GO 

PRINT 'dbo' 
SELECT * FROM atable 
GO 

EXECUTE AS USER = 'auser' 
GO 

PRINT 'aschema' 
SELECT * FROM atable 
GO 

REVERT 
GO 

Answer 2

Je ne sais pas si cela peut aider, mais vous pouvez être en mesure de faire une vue d'une autre table avec le même nom, voici un extrait de http://www.w3schools.com/SQl/sql_view.asp:

Dans SQL, une vue est un virtuel table basée sur le jeu de résultats d'une instruction SQL.

Une vue contient des lignes et des colonnes, tout comme une table réelle. Les champs d'une vue sont des champs d'une ou de plusieurs tables réelles de la base de données.

Vous pouvez ajouter des instructions SQL, WHERE et JOIN à une vue et présenter les données comme si les données provenaient d'une seule table.

Answer 3

Ceci est une très mauvaise idée. Je ne sais pas pourquoi les gens essaient toutes ces méthodes folles pour améliorer la sécurité, mais c'est tout simplement contre-productif.

En fin de compte, chaque système de sécurité se résume à une ligne comme if(User.HasAccessTo(object)). En fait, si vous avez conçu un système de sécurité bien pensé, c'est presque exactement comme cela devrait fonctionner. Plus vos vérifications d'authentification sont disjointes, plus vous risquez de commettre une erreur. Si seuls certains utilisateurs ont accès à certaines informations d'enregistrement, vous devez ajouter un indicateur à ces enregistrements et vérifier l'accès en fonction de ces informations.

Answer 4

J'utilise Postgres surtout, si YMMV, mais postgres vous devez

1) Créer le nouveau schéma, de préférence appartenant au nouveau rôle et placez-y la table 2) Définissez la variable search_path pour inclure ce schéma AVANT l'autre.

Espérons que ça aide.