Consider the problem bellow:
Every year we provide the best employee survey in our company. We want to automate this process(now we use some papers and a block box). It is easy to build a survey application but the main problem here is the privacy.
There are some requirements:
User should be able to login
User can give a vote for somebody only once
The survey should be completely anonymous even for database administrator
I guess we can achieve this with some form of database encryption. But what should I do with the keys?
A (simple) idea to hide user ID from the DBA is to encode it in the DB using the user password as a cryto key. If the executable used for the survey is somehow protected from reverse-engineering, that would provide a basic level of identity protection.
An even simpler idea:
If you are allowed to keep some paper around, you can create and distribute "voting cards". Cards with a unique ID (say, 8 or 10 characters) are distributed randomly to voters, and instead of login with his/her real name, the voter uses his (secret) ID. That way, anonymity is guaranteed, and you can do the checks you want on the votes.
Related
I am designing a back end database that will handle registration and login. I need to be able to deal with different account and authentication types.
Imagine a user registers their company online (on my website), the company details go into my company table, and their details go into my user table.
They then get the "account type" as company administrator (account type table).
That user (company administrator) can now log into their company account online, and register multiple users (in their company).
The issues I have are below, and hopefully my design solves these but I am not sure if I am on the right track.
Each user could have either a password, or a smart card to log in. I have the relationship for password and smart card tables but this means there will be many null objects. Either a user will have a password or a smart card.
Just to clarify my needs. When a user registers the company, they become a company administrator, but they could also set up other administrators and/or users, so that why I have them all in different tables.
I have added further tables as each user must have one or more forms of ID checked, along with being provided one or more access codes that will provide a range of access levels (physical and computer resource based)
I am mainly concerned that I have the right type of database normalization AND relationship design.
Lastly, the Smart Card table will have multiple smart card entries that I create, and I need to be able to assign 1 or more to a company, then, the company administrator can assign one or more of these to a user belonging to that company.
Are my relations OK for this?
What about null values until I have the smart cards assigned, is this OK?
Any help and guidance would be great.
And just to confirm, this will be a back end SQL database on my server, accessed by online web app AND end user desktop applications written in C#
I am looking for a database design that can track and manage users with attributes to systems.
Situation:
A user has access to many systems in the organization and within each system, different attributes such as date created, system login name, system user id, etc. Currently, we have a database that is a flat database so for every attribute is in one row and continues to grow as more system attributes are added. The current tool used is an Access database and the current column count is 231 columns (OMG)! This is getting out of hand.
Assumptions:
There are a lot of attributes to track and one specific table in a database shouldn't be so broad to accommodate those attributes. Creating a table for each system becomes a mess in itself because each system may change in terms of columns. We need an interface for the administrators to easily manage this.
Let me give an example:
User Sunny, who works at Google, has access to the DMV, IRS, and Whitehouse.
For the DMV, Sunny has a user name, a pin code, and authorized IP address field. For the IRS, Sunny has a tax ID number, an organization number, a clearance number, and an access expiration date. For the Whitehouse, Sunny has a user name, a password, an access schedule, a portal address, and a user type. As Sunny works at google for years and slowly things change. Sunny gets access to the NRA, HP, Facebook, and Intel. The IRS adds a department clearance information. Whitehouse requires an authorization ID. The administrators need to see what access Sunny has and looks into the system; easily they find what they need.
Conclusion
Modifying tables and adding attributes may change on a regular basis. Developing a single table to handle this seems like a chore. I need a database design that could accommodate changes like this.
Question
How should design a database to accommodate something like this?
Thanks in Advance!
PS. I asked a question that is similar to this but it was a question for a software that actually exists to do this.
I'm currently writing a messaging mobile app. I was wondering that what is the best procedure to search for friends already in the network by phone number. Like Viber, WhatsApp, SnapChat, etc. does.
What i need is:
Search through users contacts phone number if they are existing in our network (the easy part)
Notify user, if his/her friend joined to the network (the hard part)
If user adds a new contact, check if it's existing in the network (another hard part)
Which makes this hard, is that a user can have more than 1000 contacts. I can't save his/her contacts in my database as that would have policy issues. I can't iterate through every contacts every time, that's really inefficient.
How would you implement such feature in your own app?
Don't transfer real phone numbers to any server! Hash them instead (e.g. with MD5). This is far more secure and trustful!
There is no other way than iterating through all numbers every time a sync takes place. One could set an already_known_to_app=Yes attribute to all scanned contacts, then fetching only contacts without such an attribute next time you sync. Downside: you won't know which contacts have changed.
But the possibilities depend on your plattform.
I am working on my first web project. I have referenced many tutorials and pdfs but all those had simple examples for the login and sign-up feature for a webpage, which only used a single database. I am having a massive confusion on whether or not, the login and sign-up should have separate databases.
My main question is : The project intakes user's personal information(name, email, address, telephone number, etc.) along with information specific to their vehicles (model, company, make, manufacture date, etc.). And after logging into the website, both these data's are important but only some of them are in use like, the user's name, his/her address, the model of vehicle, and the company. So should I maintain separate databases for both of them and reference each element with a foreign key while working on databases ?? Or should i just bother less and use a single database and complete my login and sign-up function ??, because with the no. of columns that I have apparently is very large.
This might be a bit too academic, but a word you'll want to learn well is normalization. Here is a link to a pretty stiff definition: https://en.wikipedia.org/wiki/Database_normalization
This being your first web project, my advice would the following:
Don't be afraid to make mistakes. I would strongly encourage trying approaches you think are good and then don't be afraid to change your mind. The lessons learned will stick with you.
Keep everything simple up front. Only add complexity when you need it.
Definitely don't be afraid to grow horizontally with tables (add more and more tables). When I first started working with databases I was afraid to have too many tables because it felt wrong. Try to resist the temptation to cram everything in one table.
Definitely separate login, users and vehicle information. Not a bad idea to also separate out user address information since people can have more than one address.
You must use the same database for holding all the information for your project. Two different database is not really good idea , you can create many tables in an database. and each table is designed to hold different information.In case of your example you may choose the following tables in the same database
UserLogin [store login information]
User [ store personal info]
Vehicle
and so on
There must be one to one relationship between UserLogin and User table and one to many in user - Vehicle table
One user may have many Vehicle
Hopefully it will help
Sorry if this is an elementary question but I've just started to consider whether I've been doing this correctly all along. Usually when a user tries to update the database, I simply use his/her username as the key in a user table and then base all operations on that. However I just realized that a crafty user MIGHT be able to submit a query using another username name thus circumventing this weak form of enforcing entitlements. So my question really is how do I prevent a user from potentially submitting a destructive action against a database under a different userid?
You should store the current user's ID in the session, which isn't easily manipulated.
I usually refer to the objects through a relation on a User object:
current_user.fragile_records.find(params[:id]).destroy
It's a readable and simple way of doing an ownership test.
http://guides.rubyonrails.org/security.html is a surprisingly good read on the subject.
There are plenty of readymade solutions for maintaining user identity (authentication) and ensuring user has clearance for an action (authorization) in Rails.