Our Black Friday sale is now live! All individual subscriptions are 50% OFF. This week only!

kkontroll

kkontroll

Member Since 3 Years Ago

Experience Points
12,260
Total
Experience

2,740 experience to go until the next level!

In case you were wondering, you earn Laracasts experience when you:

  • Complete a lesson — 100pts
  • Create a forum thread — 50pts
  • Reply to a thread — 10pts
  • Leave a reply that is liked — 50pts
  • Receive a "Best Reply" award — 500pts
Lessons Completed
121
Lessons
Completed
Best Reply Awards
0
Best Reply
Awards
  • start your engines Created with Sketch.

    Start Your Engines

    Earned once you have completed your first Laracasts lesson.

  • first-thousand Created with Sketch.

    First Thousand

    Earned once you have earned your first 1000 experience points.

  • 1-year Created with Sketch.

    One Year Member

    Earned when you have been with Laracasts for 1 year.

  • 2-years Created with Sketch.

    Two Year Member

    Earned when you have been with Laracasts for 2 years.

  • 3-years Created with Sketch.

    Three Year Member

    Earned when you have been with Laracasts for 3 years.

  • 4-years Created with Sketch.

    Four Year Member

    Earned when you have been with Laracasts for 4 years.

  • 5-years Created with Sketch.

    Five Year Member

    Earned when you have been with Laracasts for 5 years.

  • school-in-session Created with Sketch.

    School In Session

    Earned when at least one Laracasts series has been fully completed.

  • welcome-newcomer Created with Sketch.

    Welcome To The Community

    Earned after your first post on the Laracasts forum.

  • full-time-student Created with Sketch.

    Full Time Learner

    Earned once 100 Laracasts lessons have been completed.

  • pay-it-forward Created with Sketch.

    Pay It Forward

    Earned once you receive your first "Best Reply" award on the Laracasts forum.

  • subscriber Created with Sketch.

    Subscriber

    Earned if you are a paying Laracasts subscriber.

  • lifer Created with Sketch.

    Lifer

    Earned if you have a lifetime subscription to Laracasts.

  • evangelist Created with Sketch.

    Laracasts Evangelist

    Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.

  • chatty-cathy Created with Sketch.

    Chatty Cathy

    Earned once you have achieved 500 forum replies.

  • lara-veteran Created with Sketch.

    Laracasts Veteran

    Earned once your experience points passes 100,000.

  • 10k-strong Created with Sketch.

    Ten Thousand Strong

    Earned once your experience points hits 10,000.

  • lara-master Created with Sketch.

    Laracasts Master

    Earned once 1000 Laracasts lessons have been completed.

  • laracasts-tutor Created with Sketch.

    Laracasts Tutor

    Earned once your "Best Reply" award count is 100 or more.

  • laracasts-sensei Created with Sketch.

    Laracasts Sensei

    Earned once your experience points passes 1 million.

  • top-50 Created with Sketch.

    Top 50

    Earned once your experience points ranks in the top 50 of all Laracasts users.

Level 3
12,260 XP
Oct
02
1 month ago
Activity icon

Replied to About Using Abort In Policy.

I would agree that using return false and return true could be changed to $this->deny() or $this->allow() - the doc uses these as well. Either of these would be fine by me, though I am more accustomed to the first-mentioned alternative.

However, in so far as I have managed to understand up until now, using abort inline in the policy for denying the user access to the resources, seems unconventional to say the least. Especially since it throws a different class of exception than a developers experience in the framework would make one assume. My understanding is that you are somewhat of the same opinion, though you might have different reasons for it.

I was not aware of the abort_if example that you gave, I will have to look into that. Thank you for the suggestion!

By whitelisting/blacklisting, I mean that in my original post everyone is assumed to authorized, except those explicitly being denied. I believe that is called "blacklisting", and from what I have found it is frowned upon security-wise and also conventionally in Laravel - as I believe you touched upon. Is it not more "healthy" to assume everyone is denied, other than those you identify to explicitly have access?

I am not sure what I am looking for here. I think I just needed fresh input for an internal discussion which seems to be a bit locked. Hence, I am investigating whether I am unaccepting to new things, or if my concerns are genuine and worthwhile.

Activity icon

Replied to About Using Abort In Policy.

There is no catch in the Controller, everything is handled at framework level because both approaches generate the appropriate response.

Assuming that we would want to have a different error message depending on where the policy is used, would we not have to try-catch the authorize call then?

From my prior experience with Laravel, if I want to handle the return from a policy, then I would have to catch an AuthorizationException in the controller, adjust the error message, and return the "appropriately" formed response from the controller. That would fail if we are using abort, because that throws a different class of exception. I would imagine that is unfortunate - am I being a stickler?

My personal opinion would be to stick with the framework conventions [...]

I think that is my stance on it as well, but what are those conventions? Does my first example follow those conventions in your opinion? Surely, at least it should be return $this->deny('Your user is not activated yet'), or maybe I misunderstood you here. I apologize if that is the case.

Do you have an opinion on whitelisting/blacklisting in policies? I would be interested in hearing about it if you do.

Activity icon

Replied to About Using Abort In Policy.

Well for my part I am unsure. Should it matter? And that is part of what I am trying to figure out. I am not facing one problem or a bug, I think my question is more in terms of best practice and what is proper, and in part how things should be done.

What could the consequences be when throwing HttpException instead of AuthorizationException? In a controller, if we do $this->authorize(...) we would have to catch a different exception. We could just change those and do that, but does it matter? For now all I know is that it appears to be possible, but it feels weird and off.

Would it, assumedly, be more secure to use whitelisting instead of blacklisting?

The method does not really return anything, ever, in cases of "denial". Does it matter? The whole premise feels wrong, but it appears to work in practice.

It is in an API context, if that makes a difference, and the reasoning seems to be that this will automatically return 403 with a predefined message whenever one tries to authorize for this action.

I guess I am a bit biased, but I am honestly just trying to figure this out to iron out an internal issue and to learn something new.

Edit: What would your initial reaction be if you came across a system of policies written in this matter when working on an API?

Activity icon

Replied to About Using Abort In Policy.

Yes, I am aware of this possibility, and that is an alternative. But I was looking for more good and bad about the implementation i referred to.

I appreciate taking the time to give feedback, thank you :)

Activity icon

Started a new Conversation About Using Abort In Policy.

I am currently faced with this pattern of writing policies:

public function update(User $user): bool
{
    if ($user->isDeleted()) {
        abort(403, "Your user has been deleted");
    }

    if (! $user->isActive()) {
        abort(403, "Your user is not activated yet");
    }

    return true;
}

Consequently, I am a bit perplexed and I was hoping for some educated input and comments about this way of writing polices. Good and bad. I would appreciate any feedback.