I'm working on a project with Redis Client "Free Redis"
So I did multiple users and restrict them with different databases using "Acl_setuser"
but all the users still have access to write in database number 0.
how can I restrict them from using it?
Related
I need to set up a training database on Azure that will allow all users to run Select statements (nothing else, it will be read-only).
Multiple users would all be logging in as the same read-only login, and creating/running select statements via SSMS or some other tool.
Any caveats to doing this? I'm planning on opening up the firewall and allowing all IP addresses to access it.
You can use the AdventureWorkLT database that you can install from Azure portal as shown here.
Take in consideration that Basic tier only allows 300 sessions and 30 concurrent logins. You may have to use Standard tiers depending on the number of sessions expected. Please visit this documentation for more information about limits of Azure SQL tiers.
I'm using CouchDB 2.1.0 and for my use case I would like non-admin users to be able to create their own databases that they will then have write/read access to, and the ability to add other users with write/read access.
Note that this is not one database per user, which seems to be the common use case, but many user-created databases per user.
Users are being created right now by POSTing to the _users database. Authentication is being handled by CouchDB's built-in authentication.
I could create a backend service that has admin credentials that would create these databases, but I would like to avoid doing so. Reading through docs it seems like by default CouchDB only allows admins to create databases; is there a way to change this?
Honestly, I think the only real answer here is that you'll have to make a backend service that has admin credentials that can create new databases. Kind of a bummer since one of my goals for this project was "no backend other than CouchDB".
My backend service ended up just taking a list of users that should have access to the created database, creating the database with a unique ID, and returning that ID. I then have a document in each user's DB that lists all of the DBs they have created.
I understand there is a Domino ini setting for turning off all FT-indexing for an entire server. But is there any way to do this for only some databases on the sever, possibly on a per folder basis?
A fulltext can only be created by a user with manager access to the database.
In a well configured environment NO USER needs manager access to ANY database.
Even administrators don't need that (as there is Full Administration Mode).
So: Give users editor to the databases, manage access to databases with groups (user managed groups if you want), and then decide which databases to index.
In the end give the rules about which databases should have an index to the admins...
I was looking at https://azure.microsoft.com/en-us/documentation/articles/sql-database-manage-logins/ searching for some documentation about limits and/or restrictions of the amount of the users I can create on SQL Azure Server, but I didn't get anyone.
There's no specific limit on number of users. A SQL database can handle 2^31 objects which includes tables, views, sprocs, etc... and users so you can create LOTS of users (doesn't mean you should).
The article you referenced points out the maximum concurrent logins of 30. That means only 30 unique logins are permitted at any time. For most environments, this translates to 30 concurrent users. That means you can create 1000 user accounts in your database but only 30 can actively access the database at any given time.
I'd be happy to help. Can you please be a little more specific about what limits you think you might hit? There are no limits on users for security in SQL DB.
Guy
We have a system with 2 clients (which will increase). These two clients connect to the same server/database, however neither should be able to see the others sensitive information. There is however some shared non sensitive information.
There is also an administrative department who does work on behalf on both of the clients. They are allowed to see all sensitive data.
We currently handle this by holding a ClientID against the tables in question and with a mixture of views and queries check against the ClientID to control access for each client.
I want to move to a consistent handling of this in our system e.g. all views, or all queries, however I just wondered if there was perhaps an easier/ better Pattern than using views to handle this situation?
We're using Sql Server 2005 however upgrade to 2008 is possible.
Cheers
the most logical way is to have (indexed) views filtered by what each user can see.
add read/write permisisons to each client for their views. admins access the tables directly.
but it looks to me that each client is a logicaly separated entity form the others.
if that's the case you might consider having 1 db per client and 1 db for shared stuff.
admins can access everything, each client cas only access it's own db and read from common db.
a 3rd option is to look into schemas and separate your clients there.