I'm writing a software application to let the people have their own private archive of cooking recipes.
The RecipeController constructor contains:
$this->middleware('auth')
because only registered users can use recipes, but I need to protect also the access to the models.
The point is that users can view and modify only their own recipes.
Example: The user TortelliEngineer can create a recipe "Tortelli Secret Recipe" using the model Recipe; he can view, update and delete his recipe(s), but nobody else can see his precious "Tortelli Secret Recipe".
So, which is the cleanest way?
I added a user_id attribute to the model Recipe.
I must use this parameter every single time that I ask to the database for a Recipe (goodbye "findOrFail" by ID)
That means that every time I make a request I must access the Request object that contains User that contains User_id
using Auth::id() EVERY SINGLE TIME that I need one (or n) recipe
Like this:
class RecipeRepository{
public function all(){
return Recipe::where('user_id', Auth::id())
->orderBy('created_at', 'asc')
->get();
}
public function find($recipe_id){
return Recipe::where('user_id', Auth::id())
->where('id', $recipe_id)
->firstOrFail();
}
Is that correct? Do you hate me for this? Do you know better or more correct ways to do it?
Most of the time I make a method inside the model to check if someone is authorised, owner etc.. of something.
An example would be:
// User model
public function owns_recipe($recipe)
{
return ($recipe->user_id == $this->id);
}
You can call this at the very beginning in of the methods of your controller:
// Controller
public function index (Request $request)
{
$recipe = Recipe::find($request->id); // Get recipe
$user = ... // Get user somehow
if (!$recipe) App::abort(404); // Show 404 not found, or something
if (!$user->owns_recipe($recipe)) App::abort(403); // Show 403 permission denied, or something
... // Do whatever you want :)
}
While there are many ways of approaching this, Laravel does provide some built-in methods for handling general authentication of actions. In the first place I'd do something along the lines of what you intended (have a getRecipesByOwner method in RecipeRepository) and you can pass the user to it from the injected Request object:
// RecipeController
public function index(Request $request)
{
$recipes = $this->recipeRepo->findRecipesByOwner($request->user());
}
In addition though, I'd recommend creating policies to manage whether or not a user is capable of updating/deleting/viewing individual recipes. You can then authorize their actions in the controllers/blade templates/etc. via built-in methods like:
// Controller
public function update(Request $request, Recipe $recipe)
{
$this->authorize('update', $recipe);
}
// Blade template
#can('update', $recipe)
#endcan
The documentation is available at: https://laravel.com/docs/5.3/authorization#creating-policies
Related
I need to know how to assert that Laravel Controller returns view with proper data.
My simple controller function:
public function index() {
$users = User::all();
return view('user.index', ['users' => $users]);
}
I am using functions such as assertViewIs to get know if proper view file is loaded:
$response->assertViewIs('user.index');
Also using asserViewHas to know that "users" variable is taken:
$response->assertViewHas('users');
But I do not know how to assert if retrieve collection of users contain given users or not.
Thanks in advance.
In tests I would use the RefreshDatabase trait to get a clean database on each test. This allows you to create the data you need for that test and make assumptions on this data.
The test could then look something like this:
// Do not forget to use the RefreshDatabase trait in your test class.
use RefreshDatabase;
// ...
/** #test */
public function index_view_displays_users()
{
// Given: a list of users
factory(User::class, 5)->create();
// When: I visit the index page
$response = $this->get(route('index'));
// Then: I expect the view to have the correct users variable
$response->assertViewHas('users', User::all());
}
The key is to use the trait. When you now create the 5 dummy users with the factory, these will be the only ones in your database for that test, therefore the Users::all() call in your controller will return only those users.
I am currently adding permissions/roles/authorization to a Laravel application.
In the application's database are users, companies and products. Companies have many users and a product belongs to a company.
Now I want to authorize company users, to create a product for their company.
In my ProductController.php I have something like this:
public function create(Request $request)
{
$company = Company::findOrFail($request->get('company_id'));
return view('product.create', compact('company');
}
One option would be to use Gate::authorize() after getting the company and pass the $company to the authorize-method.
Question: But how can I solve this, if I don't want to use Gate::authorize(). So in case I want to use policies?
Another Question: I see several ways to authorize: Gate::authorize(), policies, StoreProduct's authorize(), ...
Which one should I use? Should I always implement StoreProduct's authorize() event if I use policies for example?
You can have the create ability on the ProductPolicy take a Company instance as an argument and you can then check that the User belongs to that Company in the policy:
use App\Company;
use App\User;
class ProductPolicy
{
public function create(User $user, Company $company)
{
return $user->company_id === $company->id;
}
...
}
You can call authorize in your Controller to use the ProductPolicy to authorize the User. These authorization methods can take an array as the second argument which allows you to send additional data [the first argument will be the model for the policy, in this case it doesn't take an instance, but we still need it to know which model's policy we want so it takes the class name]. This will check the create ability on the policy for Product and pass it an additional value of $company:
use App\Company;
use App\Product;
...
public function create(Request $request)
{
$company = Company::findOrFail($request->input('company_id'));
$this->authorize('create', [Product::class, $company]);
return view('product.create', compact('company');
}
Remember to register the Policy for the Product model.
You have options for how you want to do authorization, that is why there are different methods to achieve it. Depends what you prefer or what fits your current need.
I have the following policy which determines if a user is able to view a contract.
public function view(User $user, Contract $contract)
{
if ($user->user_type->id == 2) { // If user is a vecino
if ($user->id == $contract->customer_id) {
return true;
}
} else if ($user->user_type->is_admin == true) { // If user is an admin
return true;
}
return false;
}
Which is then checked for authorization with
$this->authorize('view', $contract);
How do I check authorization for a list/array/collection? Like if I get a list of contracts via Contract::all()
I haven't found any way to do this. I could do a loop and call $this->authorize for every iteration to check for authorization but that might impact performance.
Is there a better way of doing this?
One solution I am currently using is a hybrid approach where you define your rules within a scope and then reference that scope from the policy allowing you to reuse your authorization logic.
// Contract model
public function scopeViewable($query)
{
// If the user is admin, just return the query unfiltered.
if (Auth::user()->user_type->is_admin) {
return $query;
}
// Check the contract belongs to the logged in user.
return $query->where('customer_id', Auth::id());
}
And then in your policy, reference that scope but restrict it to the current model. Make sure to return a boolean using exists(). This essentially checks that your model is viewable.
// Contract Policy
public function view(User $user, Contract $contract)
{
return Contract::viewable()
->where('id', $contract->id)
->exists()
;
}
Importantly, you should use the scope when retrieving a collection of models and not the policy which would run the scope query for each model in the collection. Policies should be used on individual model instances.
Contract::viewable()->paginate(10);
// Or
Contract::viewable()->get();
But, when you want to check an individual contract you can use your policy directly.
$this->authorize('view', $contract);
// Or
Auth::user()->can('view', [Contract::class, $contract]);
The design i often sees in this case, is to check if all elements in the query is allowed to be viewed through the policy. This does not scale well and works bad with pagination.
Instead of filtering out the contracts with policies, the better solution is to filter the contracts already in the query. This mainly because if you want to do pagination down the line, you want to do all filtering before the query is executed to avoid having weird pagination meta data. While also having to run n operations for each element, which would already be a problem at 1000 elements.
There for doing the following query clause, can obtain the same result as your policy.
Contract::where('user_id', $user->id)->get();
A version of this i usually do to make things easier for my self is creating a scope in the user model.
public function scopeOwned($query, User $user)
{
return $this->query->where('user_id', $user->id);
}
Contract::owned($user)->get();
You have to loop, one way to another. There is no difference between looping over Contract object in your controller, or on your policy, but policies are made to check a single resource so I would do that in your controller.
In my crud controller I am trying to get the name of the person who is currently being edited.
so
http://192.168.10.10/admin/people/93/edit
In the people crud controller
public function setup() {
dd(\App\Models\People::get()->first()->name)
}
This returns the first person not the person currently being edited.
How do I return the current person (with an id of 93 in this example)
Ok, So since you use backpack look into CrudController to see how the method looks:
public function edit($id)
{
$this->crud->hasAccessOrFail('update');
$this->data['entry'] = $this->crud->getEntry($id);
$this->data['crud'] = $this->crud;
$this->data['fields'] = $this->crud->getUpdateFields($id);
$this->data['id'] = $id;
return view('crud::edit', $this->data);
}
So now you can overwrite the edit function and change whatever you want. You can even create a custom edit page if you so wish.
Setup on the other hand is usually used to add things like
$this->crud->addClause(...);
Or you can even get the entire constructor and put it in the setup method because setup call looks like this:
public function __construct()
{
// call the setup function inside this closure to also have the request there
// this way, developers can use things stored in session (auth variables, etc)
$this->middleware(function ($request, $next) {
$this->setup();
return $next($request);
});
}
So you could do something like \Auth::user()->id;
Also it's normal to work like this. If you only use pure laravel you will only have access to the current id in the routes that you set accordingly.
Rahman said about find($id) method. If you want to abort 404 exception just use method findOrFail($id). In my opinion it's better way, because find($id)->name can throw
"Trying to get property of non-object error ..."
findOrFail($id) first fetch user with specified ID. If doesn't exists just throw 404, not 500.
The best answer is:
public function edit($id)
{
return \App\Models\People::findOrFail($id);
}
Good luck.
you need person against id, try below
public function setup($id) {
dd(\App\Models\People::find($id)->name);
}
Lets say I have UserControler that handles user creation deletion etc and Comments conntroler that handles comment's adding deleting modyfing etc.
What If my user wants to add a comment? Should the userController have addComment method? Or should I handle this in commentsController(if so how do I pass user data)?
Maybe I don't need commentsController at all?
How do I design it properly according to MVC(I am using laravel)?
You can always get the authenticated user info using these methods:
//Will return the authenticated User object via Guard Facade.
$user = \Auth::user();
//Will return the User Object that generated the resquest via Request facade.
$user = \Request::user();
If you set your route to something like this:
Route::get('posts/{posts}/comments/create', 'CommentsController#create');
Then you can create a button (i'll use bootstrap here and hipotetical ids) that points to:
Create
On your CommentsController you can have something like this:
public function create($post_id)
{
$user = .... (use one of the methods above);
$post = ... (get the post to be commented, if thats the case)
... Call the create comment function
return redirect(url('posts/9'));
}
Immediate answer would be CommentController , this is the controller that should add/delete/edit comments.
Can any one else add/delete/edit comments other than users? If yes, are they going to go into same business/domain object?
Lets say if you have User Comments and Customer Comments have separate Business/Domain comment objects , in this case you may have separate UserCommentsController and CustomerCommentsController.
And as #Arthur Samarcos suggested you can get user info.
In a case like this where each comment belongs to only one user, I would set that up in the comment controller because the user id is really just another attribute of that comment.
Additionally, I find it best to abstract this logic to a repository in the case you will need to eventually create a comment from another controller or somewhere else in your app. Maybe if the user takes some action you want to auto-generate comments when those actions are taken. The repository could look like this...
class CommentRepository {
protected $comment;
public function __construct(Comment $comment)
{
$this->comment = $comment;
}
public function newComment($user_id, $content)
{
$comment = $this->comment->newInstance();
$comment->user_id = $user_id;
$comment->content = $content;
$comment->save();
return $comment;
}
}
Then you'd inject that repository into your controller which would look something like this...
class CommentController extends BaseController {
protected $cr;
public function __construct(CommentRepository $cr)
{
$this->cr = $cr;
}
public function create()
{
$comment = $this->cr->newComment(Auth::user()->id, Input::get('content'));
return Redirect::route('comments.index');
}
}
There are a few benefits to this approach. One as I said earlier, it makes your code reusable and easy to understand. All you need to do is inject the repository into your controller where you need it. Two is it becomes much more testable.