Feature: Indicate default endpoints for authorization about jetbrains-laravel-make-integration HOT 4 OPEN

Originally I was only going only for a marking based on method name, but it seems like it's actually not that difficult, the middleware appears in the JSON output:

{
    "domain": "demo.test",
    "method": "GET|HEAD",
    "uri": "ajax/cis/create",
    "name": "ajax.cis.create",
    "action": "App\\Http\\Controllers\\Ajax\\CiAjaxController@create",
    "middleware": [
      "web",
      "backend",
      "auth",
      "can:create,App\\Models\\Ci" // <-- here
    ]
}

from jetbrains-laravel-make-integration.

That's a really nice idea. I had something similar in mind for endpoints that require authentication, but never thought of authorization. Maybe the gutter icon could have a little 🔒 in the lower right corner.

The implementation might require lots of effort. At the moment the plugin receives its information by running artisan route:list --json. This includes e.g the class and method name, which is how we can map the routes to the source code. I don't think the output contains information regarding any policies. We would need to retrieve this somewhere else, maybe by executing code in the context of the application using artisan tinker.

from jetbrains-laravel-make-integration.

That's very good news and simplifies the implementation a lot!

I think a "proper" would also check that the can middleware alias resolves to \Illuminate\Auth\Middleware\Authorize, but I think this can just be assumed for the initial version. Similar assumptions should be reasonable for the auth middleware.

For the logo I think it would be reasonable to replace the globe in the existing icon with a lock (e.g. search for "lock" on the JetBrains Icons List). Not sure how to differentiate authorization and authentication here (maybe only one applies, but as in your example, both could be required).

Since the endpoint is also "connected" to a specific policy method, the plugin could maybe add it to the "related symbol" list, which might ease navigation. But I am not 100% sure how to do that or if this API is publicly accessible.

from jetbrains-laravel-make-integration.

Assuming that can and auth resolve to the standard middlewares is fair I think, nobody in their fair mind should replace them with something fundamentally/functionally different (imo).
Personally I think having authorization without authentication makes absolutely no sense (although some might do that as a shortcut maybe?), so handling that case imo doesn't make any sense.
Going back to the policy is tricky at best I think considering how many ways there are to set one and them falling back to the next one, not sure if that is worthwhile. Probably easier to parse the arguments of the middleware and display that in some manner.

from jetbrains-laravel-make-integration.