I have problem to find the best way how isolate users data stored in db.
Now if i login and access to my profile i can see data loaded from db.
example .../myprofile/PeterM
but if i manualy change address to .../myprofile/MartaM i see data stored in db for user marta
how can i isolate members data.
Thanks for my maybe stupid question.
You should always check that the user who is accessing the data is allowed to do so. Don't rely on just the querystring.
So for instance, instead of performing your database lookup based on the username in the querystring, get the information based off the currently authenticated user.
If I'm logged in as Brandon, then GetUser(HttpContext.Current.User.Identity.Name); should always return my information, regardless of whose name is passed in to the controller action.
Or just check that the username you're retrieving is the same as HttpContext.Current.User.Identity.Name
Related
I want to create an app with IONIC to manage buildings. A user can hold multiple buildings. Each building has rooms. Each rooms has logs. Each user is a member of a cooperation.
For many years I've used LAMP. Now moving to mobile and made some IONIC apps. With 2 apps I've used sqlLite as datastore on the mobile device.
But now I've read up on couchDB and pouchDB and really like the concept and the sync option. So now I'm looking into this to use as my datastore (on the mobile and also on the backend).
Now I've got 2 major questions/concerns:
1) Authentication
In my LAMP situation, I usually have an SESSION (table which holds the sessions strings and userID) and an USERS table.
When the user logs in, the user is lookup in the USERS table, and a session string is created and saved with the userID.
Now each time a request is made to the server (for example update data), the session string is also supplied and matched to the SESSION table and retrieve the correct user. From that point on, I can validate if the post is valid and the data also belongs to the correct user.
Back to couchDB, I know there is a cookie management in couchDB (http://guide.couchdb.org/editions/1/en/security.html).
So here I can validate if an user exists and validate the credentials. Now the app can send requests with a cookie.
2) Fetch/Update the right data
In my LAMP situation, I always knew which data belongs to which user. And the back end always checks if this is correct.
In my couchDB I want to create database and each document is an user with all the data.
So now here comes the problem. I can validate an user in couchDB, put there's no way to validate the data (at least as far I know of) that it belongs to the right user.
My goal is that the mobile device syncs the document to the couchDB server.
3) Database structure
At first I wanted to create a database per user. But this is not scalable. Also an user is an member of a cooperation. I also need to generate reports per cooperation/user.
So now I was thinking to create a database per cooperation. But now the problem is, when a user login, I need to know wich database to connect to lookup the user data.
Now I want to use 1 database and each document is an user and holds al data (buildings/logs).
Has anybody got some other suggestions/resources on this approach?
You can try couchdb in combination with superlogin:
SuperLogin is a full-featured NodeJS/Express user authentication solution for APIs and Single Page Apps (SPA) using CouchDB or Cloudant.
github
Tutorial
I am building a web-app with Meteor and i am using the Meteor Accounts-password package and accounts-facebook package to make login easy. The user has some information tied to them like email & password, but i want to tie more information to them after the account has been created.
I know of two ways that i could do that and i was wondering how i should do it, since i can't seem to find any information about it on the internet.
Option 1:
I add all the additional information (like username, displayname and other stuff) inside the Meteor.user.profile object. This seems to be a bad solution since users by default have access to everything in the profile object and i have to manually deny them access.
Option 2:
I create a new collection, Profile-information, and store all additional data about the user and then tie it to the meteor.user object via some shared key. This also seems like a bad solution since i have to split my data like in SQL and not have all the advantages of embedded documents in mongodb.
This has been my thought process so far and i am at a loss of how to continue.
Which option seems to be the best way, or is there an option 3 that would work better?
Thanks in advance.
Thanks to #forallepsilon i found out that you could write any data to the user object you want. I previously though that the user object was locked, and you could only store additional data in the profile field.
I will store the additional data i have about the user inside the Meteor.user object by just creating additional fields.
I'm in the process of designing my data model for an iOS application where I'm using Parse for the backend (first time using Parse)
Every user of my application has both private data that should be readable and writable only by the owner of the data and public data which should be readable by everyone.
I'm considering keeping my publicly readable data stored in Parse's built in User object and the private data in another custom object. Is there any downside to this? My app uses Facebook Login exclusively and, thus, when a user is created the authData field is populated with "Facebook: 12345..." Is having this accessible to everyone a security problem?
In this scenario the User object (my public data) would need "Get" not "find" permissions, I just need it to be readable by anyone who knows the objectId. So that rules out anyone just dumping my entire User's table.
I've read through the documentation and the "sensitivity" of each user's authData wasn't clear. I realize that if I were using a traditional username/password scheme it would be a problem, but is it for Facebook login? Any help/tips are appreciated.
EDIT:
I printed an entire user object to the console on a test client (with another, different user logged in) and authData wasn't returned. Am I right to assume that my suggested strategy wouldn't be a problem then? authData appears to be a "special" field that isn't returned if another user fetches it.
I am writing an ERM application using the Zend Framework in which user accounts are created under a main company account, enabling me to limit the number of user accounts for a company based on the license which the company paid for. Each company account has its own database (with identical structure to other companies) on my server to store data relevant to that company. The name of each companies database is stored in my "back end" database along with the rest of the companies account information and license key. The authentication system works as follows:
A new user (having never used the application before) lands on the index page and is greeted by a single text field for "Company Account Number"
After clicking "Submit", the next step in authentication is for username and password. When the user submits this form, all three pieces of information (account number, user name and password) are sent to my application's Authentication handler.
My "back end" database which stores company accounts is first queried to see if the account entered by the user exists. If it does, the company_db_name column is returned and a connection established then saved in the Zend_Registry. Otherwise, authentication has failed.
If the company account does exist, the database that was returned then has its users table queried for the specified username and password hash which either returns a successful instance of MyApp_Auth or false if the credentials were incorrect.
At first, I planned on storing user session data in the individual companies database, however I have run into the problem that there is no connection to this database when first landing on the application's index page. I have planned a workaround as follows:
Move my session storage table out of the customer's database to my "backend" database, which has a connection as soon as the application launches.
Add a "company account number" column to the table and index this column.
When a user lands on the application index page, the backend database can then be queried for the current user agent's sessionid. If it is found, then return all the necessary information i.e. the company database name to establish a connection, and the user's information to build a model with.
I have a couple questions regarding this approach:
Question 1 : Is there any risk in storing all session information for every user of my application in a single back-end database table? I am thinking in the multi-thousand user mindset.
Question 2 : I am concerned that a new user may visit the index page and by complete chance (understanding that this is a very low possibility, but still possible) have the same session_id as an existing session in the back-end database. Is this a valid concern, and if so, can it be mitigated?
Question 3 : Is there a better way, or would you recommend a different method to achieve my required functionality?
Thank you for your time!
To answer your 3 questions:
Answer 1. The is not risk as such for the storing session information of every user as long as you remove it on session expiration. The issue here is "scalability" what approach are you using? Is it scalable enough? What is the write/read speed? MySQL is 'structured' approach just like MSSQL. What processing time are you looking for? How much of information is stored? What is the architectural studies. Is it feasible enough for your client?
Answer 2. Ideally the session_id will not be the same so that should not be your concern.
Answer 3. You need NoSQL (Not Only SQL but, even more) approach. Read this
Looking at the MASSIVE-ness of your data, I strongly suggest you to go for HBASE (uses Hadoop, easy for multi cluster) or CouchDB or if you are Amazon fan dynamoDB.
Questions? :)
EDIT: Just realized you are using Zend Framework. In that case, you can also use MongoDB, and use Shanty Mongo library.
I am building a database-backed web application with an administrator module and a user module. The administrator module allows an admin to modify properties of entities stored in the database. The user module serves dynamically generated forms based on the state of the database.
Consider the following use case:
A user requests a web page containing a form where the form options presented represent DB entities that meet a certain criteria
The requested page containing the dynamically generated form loads.
The admin makes changes in the DB to some entities loaded in the form such that they no longer meet the criteria to be displayed in the form (ie inactivated, deassociated)
The user submits the form with at least one entity selected that no longer meets the criteria to be displayed in the form.
Should the server-side validation of the submitted form pass or fail in this scenario?
The user was served a valid form but the posted form content is no longer valid with respect to the current state of the DB due to admin changes while the user was on the page...
If it should pass, should I be validating the data against the state of the database when the page loaded (leveraging the database history or using the session) or is that overkill and instead I could just validate that the posted entity is valid but does not necessarily meet the current form criteria?
its better if you dont change db properties. changing db properties will cause errors in your webapplication. try to make a form for admin in which the value of the forms is taken and displayed from the database. in this way only the values contained in the db will be modified by admin. by using this method your db properties will remain intact. And try not to give admin direct access to db.
The treatment should be similar to how a "Lost Update" problem is handled, as this IS a lost update problem. Two people pick up a row to edit at the same time, whose changes are persisted and whose changes are lost? The first guy's changes are persisted and the second guy is notified that the update failed - is the standard approach. In this case, the admin is the first guy to update - though the user might have been the first guy to read. So, the validation fails and the user is notified that the data is stale and presented with current data.
Hope this helps.