Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I wanna create a feedback database and have three types of users (teacher, student, and admin) how can I do that by using ms access 2016 ?
You'll want to run some VBA code on opening the Access db. If you do not need to secure your db from meddling and just want a way to obtain different functionality I suggest you avoid Access's security, it's tricky and problematic.
If you still want that protection you can find a lot of descriptions out in Googleland, I'll describe a simple identification scheme that avoids the built-in Access id security scheme. It does not provide any real security.
Establish/authenticate the user. Easiest way is to take advantage of unique PC userids and execute Environ$("Username") to return the ID used by the PC operator to log in with. If you cannot rely on it being unique, you may have to choose to create an initial form dialogue to set a name string.
Create an Access user table with all the userids/name strings plus their role (teacher, student, admin). Look up the result of step 1 in this table. If you don't find it put out a message about who to contact and then exit the application. If you do find it, remember the role.
In your VBA code declare a userid variable and a role variable in the global context (outside all subroutine and function definitions) and make them PUBLIC. Make sure the variable names are completely unique and do not use the same name as the module name. Store the results of step one and step two there.
Now you can code VBA code and SQL that references both global, public variables and you do not constantly have to join a role table into everything you do. To use the role variable in SQL, enclose the variable names in square brackets.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 months ago.
Improve this question
I have an idea to create database user (account with username and password that can access MS SQL database with those credentials) in a SQL stored procedure, and use those credentials in my web application, when user logs in with that account, to connect and interact with database.
This way I will be able to set permissions for each account and then it won't matter if that user manages to somehow get in touch with my database without my web app, as he will not be able to make changes that he couldn't do through my web app.
In short -> security is directly in my database, not in my web app.
As you can probably tell, I'm not well versed in this type of stuff, I bet that this is already a standard way of doing security, or there's a better way.
My question is:
Can I create a DB user in MS SQL using one of it's stored procedures?
If possible, how would I go about for example changing it's password?
Or if I want to add some more information other than just username and password, I would create a table with those new colums (for example first and last name, nickname, phone number, etc), how would I go about connecting a DB user with my table?
(I imagine it would be something like 'usernames for DB users are unique, so just save the username').
As you can see I have a broad idea, and it's still a bit messy in my head, and was wondering if someone could point me in the right direction with my train of thought.
You can create a Login / User using
USE MyDatabase
CREATE LOGIN MyLogin WITH PASSWORD = 'MyStrongPassword'
CREATE USER MyUser FOR LOGIN MyLogin
To change a password
ALTER LOGIN MyLogin WITH PASSWORD = 'MyNewStrongerPassword'
To grant the user access to a table within the database:
GRANT SELECT ON MyTable TO MyUser
You can indeed do this directly within a stored procedure, though I'm not sure why you'd want to - surely this would be a one off operation by a database administrator, rather than something that would require the re-usability a stored procedure gives?
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have three applications (it can be grow) and they use same database (mysql).
All those applications must have login.
So my question is which approach is database normiliztion?
One: creates user table for each application. user-app1, user-app2, user-app3. but its create a lot of tables (is it okay?)
Two: create user table once and column to indicate which app is authorize role: app1, app3. (but its create the same user for all the applications)
Or should I do in a different way?
Creating a separate user table for each application would generally be the wrong thing to do. This approach would duplicate the same data (i.e. user information) across different tables.
In fact, what you would do is have two tables:
Users
UserApplications
The first would have one row per user. It would have all the information about the users -- name, date the user is created and so on.
The second would have one row per user and application the user has signed up for. It would have additional information, such as the date they signed up for that application.
This allows you to both extend the number of users quite easily and to extend the number of applications (or to remove application).
The best way to evaluate this is to see whether
Knowing data about your user from one application differs from the other
Will these users use multiple applications together
If users will have 80-90% similar properties e.g. email, name, password hash, etc. and you expect them not to change then approach 2 works best. If you also expect these users to use multiple of these applications then it's definitely 2.
If users will have very different properties i.e. some users for app1 don't have emails but app2 needs emails and some users for app2 don't have names but app1 needs names then you might want to keep them in separate tables for data cleanliness.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Currently working on booking management system. This is a multitenant application and there will be around 50 tenants.
We are planning to host this ASP.Net MVC4/SQL Server 2008 application in some hosting provider like winasp.net, etc(Yet to decide)
Business Model Diagram
There are many levels of users like Super Admin, Tenant Admin, Customer Service, Doctors are described in the above pics.
For achieving this as a Database model, we chosen Shared Database with Shared Schema approach mentioned in MSDN Multitenant Data Architecture
Mean we added a column TenantId in each table
Our shared database & shared schema decision was made based on the below
No of tenants (50 +)
Easy to share the common meta data between the tenants
Moving big tenant(one/two) into a seperate instance if a tenant have more volume of data
We are now in progress and we still afraid of below issues to address
Data Security -> Everytime need to pass/check TenantId
Backup for a single tenant --> Need to write a SQL query for backup and Considering foreign key/auto increment is headache at backup
Data volume. Single database stores all tenant data, Querying data is slow
Indexing (Not sure whether we need to index all TenantId column in each table, since it involves in all WHERE
There are other options like
Single database/tenant
Shared database, seperate Schema
Also This Article has added some more approaches
We would like to get some advise/better design for our current design.
New approach match the above business diagram
A tenant admin/customer service user must be able to see the sub tenant records
Query performamce
Common Meta data sharing between tenant
Tenant Specific Meta data
Tenant Specific Data Fields (optional)
Easy backup
Seems to me that you should revisit your decision of having a shared database. If you have a requirement of strict data separation because of the confidentiality than you should have separate databases.
Indexing (Not sure whether we need to index all TenantId column in each table,
since it involves in all WHERE
Yes, you will have to index TenantId in each table and include it in all the queries.
Also, it looks like you've made a decision of using SQL Server before you analysed the requirements. There are probably more natural solutions for storing multitenant data, ie. RavenDB, that will make sharding / backups much simpler. I don't want to start any discussion about nosql, etc. - just suggesting that one should start with the requirements and choose the appropriate technology later.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have a program that accesses a local firebird database. It has write access to this database, and we need to be able to write to this database, but do not know the username/password.
Obviously, somewhere in the PC is a connection string/username/password to be able to connect to that database. What methods could I use to find this?
I've tried process monitor to see if it accesses any registry keys but can't see any.
I've checked the installation directories for configuration files.
I've decompiled some of the DAL DLL's but can't see any hardcoding anywhere!
The vendor is no longer, so we can't go to them.
Any advice appreciated!
If with "local" you mean embedded then you actually don't need to know the password - the embedded version doesn't check password. Quote from the "README_embedded.txt" file, chapter "2.3. Authentication and security":
The security database (namely security2.fdb) is not used in the embedded server and hence is not required. Any user is able to attach to any database. Since both the server and the client run in the same address space, the security becomes just an agreement between both sides which can be easily compromised.
So you actually need only the username, and for that you can use SYSDBA - the Firebird's superuser. Note that the username is still checked, even with embedded, to assign user SQL privileges.
In addition to the answer by ain regarding use of embedded, authentication in Firebird is handled by the server and its associated security database. This means that if you copy (or better: backup and restore) a Firebird database to a different server where you know the SYSDBA password, then you can simply access the database.
However if you want continuous write access from a different process to a database that is used by a Firebird server embedded in an user application: you can't. The embedded server (at least on Windows), does not allows external connections.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am creating a forum website using JSP and Servlet. I am having a confusion deciding that when a user creates a new account on my website, I should create a new database dynamically and specifically for that user that should contain his all data including his forum threads, profile, thread replies, etc. or I should use same database and create different tables like forumsThreads, userProfiles, etc. and link them with a foreign key. Which will be best way?
Create one database with multiple tables. Let me rephrase your question:
when a user creates a new account on my website, I should create a new User record dynamically
each time the user does something, I should create records in a number of tables that will store all his data including his forum threads, profile, thread replies, etc.
all his data will be linked with foreign keys
when another user creates another account, I can reuse all the programming logic and the database I used to process the first user.
Creating a whole new database per user is a big Anti-Pattern.
Do not create databases or tables dynamically. Everything you consider creating a new table (or database) for probably should just be a record in a table (or multiple tables) containing a user_id column identifying the user this record applies to.
You should not create a new database for each user, and you should also not create new tables for each user. You should have a fixed set of tables shared by all the users. For example:
User: ID, login, first name, last name
Forum: ID, name
Post: ID, forum_id (FK to Forum.id), author_id (FK to User.ID), parent_post_id (FK to Post.ID), date, subject, body