I'm going to develop a multiuser system, where people can register an account, log in, store and manage the data of the account. For example, email address idetifiers a user.
Could you tell, please, how to provide the user of one account access to the data of another account. For example, by providing a link in the account that gives access to another account.
It looks like Google Analytics uses a mechanism similar to this one to give access of one user access to the account of another user.
Thanky you very much, Oleg.
Providing code will be impossible here but, I'm going to guess at your setup and we'll see what happens.
So, you perhaps have a users table and a data table.
One option, is to allow Private and Public options on the data table. Public can data can be accessed by anyone.
The other option is to have another table dataPermissions where you associate data ids to user ids. When listing data, if the data item isn't owned by the current user, they must have a corresponding entry in the dataPermissions table.
Remember though, providing code and examples of you database structure is the best way to get a good answer.
Update
Okay, so we know that users are identified by email and can have one or many links to data. Those links can be shared to other users. Therefore, you are going to have a table for users, identified by email, and a table for data which is identified by its link.
Therefore, a user can choose to add more users to a link. For this, you would need a new table that associated users and links, i.e. a userLinks table.
Related
I have done a lot of reading on this but nothing stands out. I already have a authentication and authorisation system that can handle multiple guards and user roles (user, admin, super admin etc.)
I am trying to find out what is the best way to separate the system into totally separate accounts which have the following;
No login section
Landing page. Anyone can see without login.
Admin Section
Admin side of the system has a super-admins and then multiple admin-users.
These users can see all data from every user who has an account on the client side.
Client Section
Each user account has an owner who deals with billing, their own user admin etc.
Each client account also has a number of users (admin-users, editor-users etc.) with varying permissions.
Users on this side should only ever be able to see their own accounts data. They should not be able to ever see other accounts data.
Before Laravel, I would have an accounts table and assign a unique key to each account. Then a separate users table would contain the user along with their account key.
All database tables from this point onwards (posts, products, shipments etc.) would also have this key to ensure that the user account could only see their own data.
On top of this there would be permission tables, for granular control of what each user from either side can see.
Is my original way still suited to Laravel or is there a better way?
To separate out the accounts into their own "ecosystems" within the same code base is called multi tenancy. Basically, you scope your applications queries based on the user id and/or role which limits the available data to any given user.
Have a look at the Landlord Package.
In a very basic summary, what it does is add a where('tenant_id, auth()->id()) clause to every applicable query.
You can of course either omit the clause entirely for super admins to access all data, or apply even tighter constraints, say by adding a check for the user's role in addition to the clause, further limiting what a user can access within their respective account/organization/group etc.
Scoping can be done by any kind of relationship, you're not necessarily limited to the authenticated user's id. If your application has organizations for multiple user's you can use the organization id.
Multiple tenant ids is also possible, where a user must belong to an organization and a certain division within that organization.
Another package I've used previously is Hyn's multi-tenant.
We have same project as you mention . We create a company table and put it on the top of the hierarchy.
Then add new field all tables as company_id
And manage models over Policy -> https://laravel.com/docs/5.8/authorization
I hope this help
I'm building a website where users can pay for a certain service provided by the owner. It's not an online shop, though the payment process is pretty similar.
The problem I'm facing lies in the different 'login' options during this payment process. One can use a Facebook-account to log in, register for an account/login using his account OR choose to fill in personal info without registering.
I was thinking about a 'consumers' table (one time users without an account), a 'users' table for registered users, a 'facebook_accounts' table with the Facebook info, and a 'user_has_facebook_account' table for linking Facebook accounts to registered users based on a shared email address.
However, what if a user logs in using Facebook without having a registered account with a password... It's really giving me a headache.
Any suggestions how I would go about designing a database to support this?
I would create only one table with customers. There you can have a field with the Facebook user ID. If someone login with Facebook, you can create a new record for him (you have email address etc. from Facebook). Therefore, you can set an empty local password or require the user to set a password for your page.
You should probably be adding people that login with Facebook to the Users table and creating them a default password, as well as storing the OAuth information / keys.
Your "User" objects should be singular and just have a different method for how they became "Users" to simplify things
Currently I am using the traditional way to implement member system e.g. A user table and other related table (e.g. user_product) has a foreign key to link to that user
The problem is , how can I work with the member login through facebook?
e.g.
Should I used the retrieve info from facebook to create a new account
for them automatically in my user table?
Should I create a new table e.g. facebook user , then insert in it?
Should I just ignore the login info, without adding it to my database?
The problem I encounter is there is an user_id and people login from facebook will not have it. Therefore, when they use the function e.g. purchase , I can not insert the record. However, if I add them to my user table, there is some info. missing e.g. password, phone..... So what is the common parctise of handling login through facebook? Thanks
There are a few different ways this is handled in practice. Some services require a user to still fill in information, even after the user clicked "Login through Facebook". Unless there is information that you absolutely need, I would advise against this approach.
You could take a polymorphic approach to users and have a regular users table and a Facebook users table. There are other ways to approach inheritance in SQL databases too, but this can get complicated.
A third approach would be to have Facebook id and auth tokens as nullable columns on your users table. This would also require you to either make the password column nullable, or set it to something long and random. This way, Facebook associated accounts function identically to other accounts, with the exception of of the way they sign in. Since you have their email, it should still be possible for Facebook users to make use of a "Reset password" option to get a password.
Edit:
You'll need to create columns for the things you need in order to maintain a Facebook record for a user. Facebook id, oauth token, and oauth secret are among these. When a user clicks sign in with facebook, upon receiving a response from Facebook, you should run a check to see if there is a user with the given facebook id. If one exists, sign the user in. Otherwise, create one.
Even easier would be to look at an OmniAuth solution. OPAuth is one such solution. Introducing something like this may require you to rework some existing code though.
So I'm currently in the process of creating a small public website (where users can, for example, log in and change personal information), but I am wondering how the database security is actually designed for that type of thing, so I have several questions.
When an internet user accesses a page like stackoverflow, for example (without logging in on the site), which database user or role is he logged on in order to be able to see all the posted questions? Then, when the user logs in with his account, does his role in the database change (since he has more rights)?
If I setup my database to have a "Users" as well as a "Permissions" table, I can make sure that a user can only have access to his own data, at least application side. But how do I make sure the data is still protected database side since I suppose every public user has the same "database login" or "role"?
I know my question is probably a bit unclear, but don't hesitate to ask me for clarifications. I didn't really know where to begin.
Thanks.
P.S.: I'm currently using SQL Server
Database role doesn't change, but functions do. Users are authorized from the back end code, not from directly database. If you are trying to create logins for every single user for your database, that would not be a good aproach since there could be thousands or milions of users which somehow can have direct access to your database with some permissions.
You've almost answered your own question.
Generally, your website will run under some user account, lets call this 'IWEB', this user account will be the same for everyone that hits your website, regardless of whether the user is logged into your website or not.
IWEB will have permissions to read data from a database. That's how the anonymous users work.
In your database you will have a user table, possibly a permissions table. IWEB will be given database permissions to create new users, update users. It possibly will be prevented from deleting users.
Your application will (though IWEB) use these tables to control who has access to your application and who can update what. A bug (e.g. SQL Injection) in your application could allow a malicious user to create admin accounts, change other users passwords etc...
In certain scenarios e.g. using Windows Authentication, you can pass through the user logged into your site, translate that into a database user and given them permissions. However you are unlikely to do that for a public facing website.
You could possibly do something where the tables are not directly accessed, but are controlled through stored procedures, denying access to the underlying tables. One of the parameters is the currently logged in user, that could then control access at the database layer (prevent a user updating another users profile). Unless of course your application has a bug that could allow an attacker to change their currently logged in user.
It all depends on your security requirements. In the main though, you will control access at your application.
What's wrong with having an Anonymous user in the Users table, having the lowest privileges in the Permissions table?
To your first question: When a user first lands on a web page they have no 'role'. Your scripting will decide what the users can and cannot see.
For example you have a post that only certain user can see. That post will be hidden by default. Your script should then run a test to see if the user is currently logged in and if that user is in the permission group to view that post. If they are, then show the post.
Your database should not be accessible either way.
I'm building a PHP application where users can design products and then check out to a shopping cart if they want to.
To let the user create a design, I need to assign a user ID and design ID to store it in the database.
There are two types of users who can build designs:
registed users. To take care of this, I have no problem.
non-registered users. These are guest visitors who might play around with product designs, and then when they hit check out, only then will I ask them to sign up. But in order to store their designs, I do need to have some kind of user ID.
I thought of using a timestamp as this user's ID, but what if two users in different parts of the world create designs at the same time? What's a good strategy for generating IDs for temporary/guest user accounts? I don't just mean temporary in the php session sense, because I want them to be able to access their partially saved designs later on if they visit the site again, just like any other registered user. I will only ask them to sign up before checking out for payment.
A simple approach might be:
Use a single user table (for registered users and guests)
Assign a "user_type" flag. E.g. registered/guest
Use the table primary key or other unique value for both "types" of user
When guests check out later on, switch their "user_type".
Store other related customer details in a separate table.