Implementing middleware groups instead of global middleware, or override global middleware in modules?



  • Hello there,

    This may be a question I'm not sure at all if it's about Laravel or about AsgardCms. I'll try to write it in the most clear way possible.

    • What I'm trying to achieve:
      In the project I'm working on, the CMS frontend/UI will be only recieve and deliver JSON objects (no views will be actually drawn, except, obviously the backend).
      So I thought the preferred routes for this project will be backend and api routes.

    • What I've tried so far:

      • I successfully built modules with their routes and controllers and everything goes fantastically well... with GET requests. The problem comes with POST requests, in which I'm required to send the CSRF token.
      • I've tried to overwrite the VerifyCsrfToken creating a middleware class in the module, but it seems that the global one takes over it.
      • I thought of Laravel's middleware groups, but i've seen that they're absent in the 'global' app. Seems that implementing middleware groups there would have an impact for the rest of the modules, or well... I have not much idea about how to deal with that at this point.
      • I also thought about disabling CSRF token verification, but this is a dirty fix and obviously will imply security issues.
      • The only thing I succeeded, was to add certain routes in the $except array in the global middleware class VerifyCsrfToken [App\Http\Middleware\VerifyCsrfToken], but I'd like a more module oriented solution (if that's even possible).

    Any suggestions?

    UPDATE: The UI will be independent of the Laravel project (will be a standalone AngularJS app), so the purpose of the CMS is to feed the content of the Angular app, as well as recieve some input from it [e.g. a leave a comment section, which will be moderated from the CMS backend].


  • Global Moderator

    @zedee
    Since you want total separation you would want to send csrf token with your json data and then when you post you send it back.
    Something like this implementation.

    I think you shouldn't abandon csrf by disabling it for routes. I have never worked with angular but you can also read XSRF-TOKEN cookie by laravel in your Angular app and then send it back as X-XSRF-TOKEN header it will be picked up by laravel.



  • Okay, many thanks for your reply.

    Although the solution you're proposing is absolutely right & functional, it's not what I'm looking for (at all).

    Perhaps the content of my post wasn't clear enough. My core question is that usually, an open web API do not require a CSRF token. (I planned to control that via an auth token), so the thing was to distinguish the middleware used depending of the access. If access is via backend, then usual MIddleware. If access is via API then use a different middleware (thus, using auth token and skipping csrf on post requests).

    Is that even possible?

    Thanks!

    UPDATE: I have to add that this application will run in a controlled local environment (the only routes accessible from the Internet will be the backend ones), so the chance of this kind of attacks is almost zero -or I'd wish-. Anyway my question wants to guess which would be the 'best practice' in this case.

    Related content: Is your Web API susceptible to a CSRF exploit?


  • Global Moderator

    @zedee

    Ah now i understand.
    Well currently i can see ways of achieving what you want but that would require editing file from core installation.

    If you would like to go this way you can do something like that:
    This seems easy solution see if it's exactly what you want.
    In App/Http/Kernel.php

    1. Remove 'App\Http\Middleware\VerifyCsrfToken', from $middleware stack.
    2. Add 'csrf' => 'App\Http\Middleware\VerifyCsrfToken', to $routeMiddleware stack.

    That would globally disable csrf.

    Helpfully Asgard has config entries for enabling middleware for routes frontend, backend, api.
    For example if only backend exposed you can now add csrf middleware in config/asgard.core.core.php in backend stack, that would only require you to edit 1 file from default package.



  • @armababy

    Yep, that approach makes total sense and worked for me. Many thanks! :smiley: :thumbsup: