As i searched a lot to create the custom multi auth in laravel on single table for different different user (i.e Customer,Shopkeeper,Admin,Delivery Executives). and this is done on single table i.e. user_table which contain a column name user_type which will hold that what type of user is that, as i need to do like this because existing system was developed in PHP and having same schema but i want to upgrade to laravel so i stuck up in the very first step.
But i searched then found to create multiple tables like admin,customer and etc but for this i have to alter my current database which i dont need.
So, any one help me out how to do it exactly.
Related
I did some searching but couldn’t find a good solution for my problem. Anyway, I am really new to Laravel and this is my first project, I appreciate your help.
In my project, these is staffs table in database which holds the records for four types of staff (Staff, Manager, SalePersonnel and Secretary) and each of these three types have special attributes . However, storing all type of stuff in one table results a lot of NULLS.
I want to separate the staffs table into four tables, one parent table that has common attributes of all staff and three more table for each type of staff.
How can I do this in Laravel context? How to create a parent record and child record. Please provide a detailed answer.
Sorry for being that dumb, as I said I am new to Laravel.
i'd like to know if it's possible at all to update the table schema in a Migration through a specific Eloquent Model, or if i actually need to pass in the name of the Table and Connection every single time.
I ask this because in my case this requires an additional configuration file that my package must publish to the end users, apart from the already required table Eloquent model (which is used for other purposes)
You can update schema later and add or drop columns and/or index.
To do this you create a new migration and add the changes there. It will change the table over your previous version.
More info in Laravel documentation.
For renaming the table
Schema::rename($from, $to);
https://laravel.com/docs/5.2/migrations#renaming-and-dropping-tables
What is the correct way to relate users in parse to one another as friends?
I also want users to be able to query other users but not see all fields, like emails. Is there a way I can create a view on the users table with cloud code, and only return this to the client code?
I was thinking I can create a friends table that will have two columns with 2 pointers, 1 for each user.
thanks for any advice.
I was thinking I can create a friends table that will have two columns with 2 pointers, 1 for each user.
I'll do that too, with a status column to handle pending, blocked...etc
I also want users to be able to query other users but not see all fields, like emails.
You have to add a privateData column on user with ACL restricted to owner only, which would contain private infos such as emails...etc
Task
Retrofit an existing application to use a multi-tenant approach. It shall be possible to create tenants and each user's session should reference exactly one active tenant. Each tenant should only be able to see and update his partition of the database schema.
Approach
Create an Oracle application context that contains the tenant id
Add a tenant id column to any table that should be scoped
Create a predicate function that returns "tenant_id = sys_context('tenant_context', 'tenant_id')" for SELECT, INSERT, UPDATE and delete
Add an appropiate policy via dbms_rls to register the predicate function
This works like a charm without touching the existing application for SELECT, UPDATE and DELETE
Question
When inserting the tenant_id column doesn't get set and a security exception comes up. Is there any way that is as sleek as the predicate function to always set security related fields? I'd rather not add triggers to 300+ tables.
Sometimes asking a question provides the answer. I wasn't aware that you may use non-constant expressions in column's default values, so
alter table XXX
add column tenant_id default sys_context('tenant_context', 'tenant_id');
actually solves my problem.
Like the title says, I've been asked to come up with an estimate for retrofitting an existing asp application.
The current security mechanism controls access to different parts of the application (page-level restrictions), but has no mechanism for flagging individual records as restricted. Assigning rights to a user (using the existing, custom access management code) is no problem, but enforcing the rights is a different matter - each asp page has embedded sql - there's no use of stored procs, objects, etc.
Is the only solution to modify each table and query, or is there a better way? Any pointers, suggestions or prayers would be welcome.
This is classic asp, running on IIS6, against an oracle database.
Update: Here's a user scenario.
We have users, managers, directors, and VPs. The managers can see data created by users who report to them, but not users who report to other managers. Users can't see data created by any managers. Same thing with directors - they can see down, but their reports can't see up.
This sounds like an ideal time to implement row-level security. Oracle has a package DBMS_RLS that allows you to define arbitrary access policies that can be applied to one or more tables that limit what rows a particular user is allowed to see. Conceptually, when a user issues a query with no filters on a protected table, i.e.
SELECT *
FROM my_table
Oracle automatically and transparently inserts a WHERE clause defined by your security policy that limits the result set. You shouldn't need to make any changes to the SQL your application is executing.
Assuming you need maximum granularity, the ability to "grant" each and any row to any of very many users, then you have a many-to-many relation, yes?
So apply the following pattern:
Add a tables of users.
Then, for each restricted table, so the following:
Rename it tablename + "_base".
create a many-to-many table that
associates that table's id with a
user id, called tablename +
"allowed_user".
create a view with the name table
name that joins tablename_base to
table_name_allowed_user, with a
select* from tablename_base and
user_id from tablename_allowed_user.
This view should meet Oracle's
requirements rto be "inherently
updatable."
Now comes the hard part. You need to add "and user_id = $user_id" to every query. Find the various functions you're using to make queries. Wrap those function(s) in ones that gets the user id from the session and add that predicate.
One passable way to do this is to read select string, find the all "where"s (for subqueries there may be more that one), and replace it with "where (user = $user) and ". For queries that don't have a where, you'll need to insert this before any "group by" or "order by". This is fragile, so obviously you'll test that this works for all pages (you have an automated test for all pages, right?), and add hacks to cover special cases.
"update" statements won't have to change; "inserts" will presumably insert both to the view and then do a separate insert to the table's "allow_user" table with the id of the inserting user, to automatically grant teh inserting user acces to what he inserted.
If your number of users is more limited, or you're restricting types of users, you can go with a strategy of multiple views named for the user or type; then you'd replace tables names in the queries with the appropriate views.