How can I delete data from a table in my database? For example, put a syntax where
delete from table_users where users or password or email or name = "perico"
Here is a trick you can use with a tuple:
DELETE
FROM table_users
WHERE 'perico' IN (users, password, email, name);
Note: If you are actually storing plain text in your password column then you should stop and instead read about hashing and salting passwords. Clear text passwords in a database are a huge security risk.
Related
I'm currently trying to execute a query in Visual Studio to add a user to my database.
I've added the database to my Server Explorer and I right-clicked it and selected New query
In my tables, I have a table called dbo.User and I am trying to execute this one query.
INSERT INTO User (Username, Password, Color)
VALUES ('Craig', 'password', 'Green')
Intellisense even recognized User and for some reason Password is highlighted as a keyword
Why does it put a red line user User in INSERT INTO User saying Incorrect syntax near 'User'
User is a reserved keyword by SQL Server. To get around this, put keywords in brackets. Try the following:
INSERT INTO [User] (Username, Password, Color)
VALUES ('Craig', 'password', 'Green')
Rename your table to something that is not a reserved word. I usually name tables in the plural. One reason is because plurals have fewer conflicts (VALUES comes to mind). Another is because they contain multiple copies of the entity, so a plural seems appropriate.
So, this should work:
INSERT INTO Users (Username, Password, Color)
VALUES ('Craig', 'password', 'Green');
The list of reserved words is in the documentation.
I also strongly discourage you from storing free-text passwords in such a table. You should be encoding the password when the user types it in, so your application can never see it. Users often re-use passwords across multiple systems, so having free-text passwords anywhere is a security hole.
The goal is to allow all the "Teachers" that have access to the Faculty table to have Select permissions to only their own social security number and not everybody elses. Do any of you know how I can perform something like this? I do have all my users setup as Windows Users and I have a windows group called Teachers, if that helps.
Not possible using the standard permissions in SQL server (that I am aware of)
You will need to implement this kind of constraint in your code.
You could in theory pass in the SS# and query based on this and raise an error if they do not match.
Social security numbers shoud be encrypted so they can't see each others numbers if they call up the record. You can use a decryption proc to allow them to decrypt that checks the userid against the profile id and will only decrypt if they match.
Implementing Row-level Permissions
Row-level permissions are used for applications that store information in a single table. Each row has a column that defines a differentiating parameter, such as a user name, label or other identifier. You then create parameterized stored procedures, passing in the appropriate value. Users can see only rows that match the supplied value.
The following steps describe how to configure row-level permissions based on a user or login name.
Create the table, adding an additional column to store the name.
Create a view that has a WHERE clause based on the user name column. This will restrict the rows returned to those with the specified value. Use one of the built-in functions to specify a database user or login name. This eliminates the need to create different views for different users.
' Returns the login identification name of the user.
WHERE UserName = SUSER_SNAME()
' USER_NAME or CURRENT_USER Return the database user name.
WHERE UserName = CURRENT_USER()
Create stored procedures to select, insert, update, and delete data based on the view, not the base tables. The view provides a filter that restricts the rows returned or modified.
For stored procedures that insert data, capture the user name using the same function specified in the WHERE clause of the view and insert that value into the UserName column.
Deny all permissions on the tables and views to the public role. Users will not be able to inherit permissions from other database roles, because the WHERE clause is based on user or login names, not on roles.
Grant EXECUTE on the stored procedures to database roles. Users can only access data through the stored procedures provided.
Hello I wonder if there is way to disable repeating value in SQL Server 2012. I don't want several people to have the same login. As a primary key I am using ID. Should I change primary key from ID to Login ?
Declare the login to be unique.
Or, equivalently, create a unique index on login:
create unique index table_login on table(login);
First off, you should never store a password as plain text in the database. Store an encrypted string if the password must be recoverable, but better yet store a salted hash of the password.
You could enforce your rule by creating a unique constraint on the Login column.
Hello all I am trying to create an in instead of insert trigger which has the following syntax
create trigger HashPassword on PasswordTBl
instead of insert
as
begin
insert into PasswordTBl (PasswordProxy)
select HashBytes('MD5', '#!'+PasswordProxy)
from inserted;
insert into master.dbo.PasswordTBl1(PasswordProxy)
select PasswordProxy from inserted;
end
As pretty much clear from the trigger I want to store the hash password in original table and plain text password in backup table which is hidden from all user but the problem is anonymous user can know the secondary table name by checking the trigger.
I would be grateful if anyone can provide me a way to hide or encrypt this trigger or any alternate way to achieve the same.
Thanks in advance..
You cannot hide a trigger - but you can encrypt its source code, so regular users cannot see what's inside:
create trigger HashPassword on PasswordTBl
WITH ENCRYPTION
instead of insert
as
begin
......
It's a simple and easy protection - but also quite a weak one; there are ways to decrypt that source code again. It can keep away the sneaky employee, but certainly not a determined hacker....
Your users should not be able to read the trigger definition, even if they have rights to INSERT/UPDATE/SELECT. If they can, they have too many rights.
WITH ENCRYPTION only obfuscates the code from folk with rights already.
See GRANT VIEW DEFINITION: One, Two and Three. Note, this is implied by ALTER and db_owner rights.
One question: if someone can see the code, they can probably see your backup table... Even if it is in master the user requires rights there to write into the table because it is a different database.
If you haven't granted rights to the users or public in master, then this implies sysadmin rights. Which means someone can undo WITH ENCRYPTION easily
Lordy, this is wrong on so many levels.
Hi Experts
How I can prevent database user deleting any data in tables using triggers?
I want just Admin delete Data from tables
Thanks
Umm take away that users permission? If you don't want them doing something, 'disallow' them that right... thats why we have permissions.
Here are details on how to revoke permissions:
http://msdn.microsoft.com/en-us/library/ms186308.aspx
Any particular reason you want to use triggers?
You could simply remove the DELETE permission from the users you want to restrict. Have a look at the "Permissions" section here: http://msdn.microsoft.com/en-us/library/ms189835.aspx
EDIT: Since you say you do want to use triggers (but I really think you should reconsider) you can create a table such as:
CREATE TABLE Restricted_Users
(
user_name VARCHAR(40) PRIMARY_KEY -- Use a size appropriate to your requirements
)
Create INSTEAD OF DELETE triggers on all your tables (that's going to be a chore) which checks for the USER_NAME() in the Restricted_Users table and if they EXIST you can call RAISERROR to cause the transaction to be rolled back and display a message to the user.
Remember you will have to maintain these triggers on all new tables added to the database as well as maintaining the list of users in the Restricted_Users table whenever you add/remove users from the database.
It would be a lot simpler to use the permission system available in SQL Server (it's what it's designed for) using roles with appropriate permissions set for the tables. Then, when adding new users you only have to assign them to the appropriate role and the delete permissions are handled for you.