We have a database that we are connecting to via RODBC, the accounts have been given read only access on the database side, however if we log in via R we are able to read/write/execute. I have been using the read only command within the connection command as follows:
odbcConnect(dsn = "DSN",uid="un",pwd="pass",readOnly=T)
I've noticed that, while users cannot write to tables or write to new tables, they can create new tables. I would like to ensure that users are unable to modify the database to open this to a broader user group. Has anyone found a sure fire way to limit user access from the R side?
Per comments made by Gregor, the issue is not R side it is database side. The system that was being dealt with was performing security checks on a front end application rather than at the ODBC handshake. As such, R had no way of enforcing rules that were not enforced server side.
Related
i'm configuring Standard Geo Replication for our Azure SQL database and need to validate Disaster recovery, but still have couple doubts and cannot find more details:)
I configured Standard Geo Replication and added Secondary database.
If i want to do DR Drill, i can just stop replication, make the second database as primary and re-point my ASP.NET applications to the new database server. Just change SQL server name.
My questions are:
What if Microsoft has some issues with data center, do they automatically just re-points DNS from main SQL to secondary so i don't need to do anything, and it would be done silently and everything would work, without my change?
I was trying to find out, if there is some kind of notification, that i can configure if SQL has an issue and i can stop replication and do this process by myself. Or will microsoft somehow notify us? email,... or only SQL AZURE dashboard?
What could be the case, that i need to do DR manually? Main SQL would stop working and AZURE cannot take care of that because...?
thanks a lot for your answers
Rado
We had this issues recently, we did not receive any email's or notification.
Luckily only SQL-Azure was affected. Hence we stopped the replication and updated connection string to point to secondary.
No they do not automatically re-point DNS from primary to secondary for databases
We have external services that keeps track of our systems and notifies us when things are not right.
We had to do a manual DR.
Would love to know if any one has a workflow in place to automate it or point to the right direction.
Hope that helps.
I'm constructing a website.
In this website, people will be able to manipulate several DB tables data.
Everytime someone wants to make a CUD operation I want to log it (like and audit).
The way I see it, I should use triggers for CUD operations, but I can't understand how do I log the user, since triggers don't accept any input parameter.
NOTE: the user I want to log is the network user. I know this user when they access the website (user to log <> user logged to DB).
ANOTHER NOTE: None of my tables saves creation date, creator, update date and updator. Just don't know why they should when I have the audit tables.
So this is the basic problem with web apps. If you have a huge user base ( more then say 500 ), then provisioning them in the database, while this is very easily doable, it is something most web programmers, sadly, don't want to deal with and want only ONE connection user for the database. You have already shot yourself in the foot because you don't have the created_by,modified_by, created_date, modified_date in the tables. To fix this you really only have one choice:
Put the columns on the tables and force the UI people to push the "network" user name through. The rest of the columns can be handled by one very simple trigger.
Why DB audit will not help you:
The DB audit feature ONLY deals with users defined as actual users in the database, sorry that is just the way it is.
Here are some things to look at when dealing with a front end system.
You can write SP's or Packages that execute as the schema owner, but can be run by ANYONE who is defined in the database and those can handle all the INSERT, UPDATE, DELETE operations on the schema they are defined in by simply giving other users the EXECUTE privilege on that set of SP's. This give the DB fine grain control over how tables are manipulated and you only have to grans the select privilege to all the users.
You can write a SP or Package in the SYSTEM schema that allows a group of people to provision users on the system by granting the execute privilege on that SP. Within that SP you define what ROLES they are assigned and therefor can control all their access.
In the past, when I implemented my own authentication mechanisms I would have a user table with relationships to other tables in my application's MySQL database. However, now that I'm considering using ActiveDirectoryMembershipProvider, I see no way to create similar relationships between AD users and those tables.
What's the normal way to resolve this issue? Should I just accept the fact that someone could potentially insert records with user IDs that don't correspond to existing users? I don't realistically expect this to happen, but I'm used to ensuring integrity at the database level.
I think you'll have to give up on database referential integrity in this case. Just have your application code check for the existence of the Active Directory account before adding the record to the DB.
In theory, some user could go in manually and type a SQL INSERT statement which refers to an invalid AD account. But in practice, hopefully you aren't giving a bunch of users direct table access. If the application code is the only thing accessing the DB, the application code is validating the account before inserting the row, and that validation code is tested, then you should be OK.
Just to be safe, you could have a nightly batch process that validates all rows in your referencing table(s) against Active Directory. If it finds any inconsistency, it can send you an email. This won't prevent integrity violations, but at least it will let you know about them.
I don't know of anyway you could do this via MySQL. If you were using SQL server, you could write a trigger that would call a C# dll that would verify that they were an AD member. Then if they weren't you could block the insertion into the DB. You might be able to do something like this with MySQL, but my knowledge of MySQL is pretty slim.
We are going to be selling a service that will be hosted by us, and each client we host will have their own database, but there will be one centralized website. I currently have a blank database with the few things that a new client will need. What is the best way to copy this database so I can setup another client? I want to be able to do this from an .aspx page. Thanks in advance!
Update:
By .aspx page, I just meant that I need to be able to kick off the process from an .aspx page.
Update2:
We're running SQL Server 2008.
Update 3: Referencing Cade Roux's answer... Thanks for a great answer, but...
What is the reason for merging all of the databases into one, and then distinguishing clients based on an identifier in each table? Wouldn't this greatly complicate the architecture of the entire product? I would need to add these Client ID columns to practically every table, and the DAL would need to know which client data its looking for. With the current setup I have, I just switch out the connection string in the DAL, depending on which user is accessing the site. That way, after the connection string is set, I never need to worry about finding client specific data! How do these approaches compare (and should I add this as a separate question?
You have a few different options:
You can detach your empty database, then when a user signs up, copy that database and mount it under a unique name for them and map it to their account in your master database, say.
You can create a database from scratch using scripts and populate any base data either from an online template database or scripting the base data and map it to their account in your master database.
You should seriously consider going to a multi-tenant architecture where all users are in the same database (with most tables having CustomerID columns to segregate the data) if you are going to have more than a few dozen customers.
Regarding your notes about option 3 - it depends on your application. Multi-tenant can be difficult to retrofit. On the other hand, managing and upgrading hundreds of individual customer databases can be difficult in the long haul.
There are previous Stack Overflow questions regarding this:
What are the advantages of using a single database for EACH client?
One database or many?
I think I'll see about re-tagging them with multi-tenant-db or something. Anyhow, I think that this comes up as a consideration secondary to your answer about a particular tactic does show the importance of including details about your overall goals in strategy in every question on StackOverflow.
Depending on what database you're using, there are several approaches. The simplest is to ask your database software to generate SQL code for creating the database and include that with your software. Another would be to just script out in C#/VB the steps needed to recreate your empty database.
Why the need for .aspx page?
You don't say what db version you're using but in SQL2005-2008, you have the ability to "script database as" and then "create to" and have it port the sql to a query window. You could then work with that to create a stored procedure that can be called from your .aspx page.
SQL Server has a system database called 'model'. Any database objects (tables, views, stored procedures) that exist in the model are added to any new database created.
You could create your 'client database' schema as model, and any new database would have all the same tables...
But, if you need to change your database schema later, your best option is to write change scripts which are part of your code-behind file. Since changes to the 'model' database are not propagated to existing databases, the application needs to detect and upgrade the database schema as necessary.
Disadvantage to this approach: If you want a database which isn't a 'client database' then you would need to create the database, and then delete the 'client database' tables.
I would like to do both of the following things:
use audit triggers on my database tables to identify which user updated what;
use connection pooling to improve performance
For #1, I use 'system_user' in the database trigger to identify the user making the change, but this prevent me from doing #2 which requires a generic connection string.
Is there a way that I can get the best of both of these worlds?
ASP.NET/SQL Server 2005
Unfortunately, no. Identifying the user just from the database connection AND sharing database connections between users are mutually exclusive.
Store the user from your web application in the database and let your triggers go off that stored data. It might even be better to let the web app handle writing all logging information to the database.