#[DisableCsrfChecks()] no longer works

[DonutsNL]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Version

11.0.1

Bug description

Im trying to adopt the samlsso (glpisaml) plugin to the latest version of GLPI. While working with the GLPI11 beta release i was able tot disable the Csrf checking by adding the decorator: #[DisableCsrfChecks()] in the plugins controller. The code looks like:

####################################################################
    use Symfony\Component\HttpFoundation\Request;                           // Required for __invoke
    use Symfony\Component\HttpFoundation\Response;                          // Required for __invoke
    use Symfony\Component\Routing\Attribute\Route; 

   #[ ... ] 


    // SLO route
    public const SLO_ROUTE      = 'front/slo';                                  // Route being registered by __class__
    public const SLO_NAME       = 'samlsso_SLO';                            // Route name

    #[SecurityStrategy(Firewall::STRATEGY_NO_CHECK)]                  // Decorator to disable authentication check
    #[Route(self::SLO_ROUTE, name: self::SLO_NAME)]                    // Decorator to register route
    #[DisableCsrfChecks()]                                                                // Decorator to disable Csrf checking
    public function slo(Request $request): Response                       // What to do if route is invoked.
    {
        global $CFG_GLPI;
        return new Response('', 307, ['location' => $CFG_GLPI['url_base'].'/']);    // Redirect back to application root.
    }

With the glpi11 release this isnt working anymore. The csrf check is applied on external IdP SamlResponses resulting in an not allowed error.

I noticed GLPI uses the 'security_level: 0' param in its own routes but this doesnt seem to be implemented via the Symphony Route Attribute that the plugin uses.

Long story short, what would be the current 'correct' way to disable CsrfChecks on a specific plugin routes?

Thanks in advance.

Relevant log output

Page URL

No response

Steps To reproduce

Code snippet results in CsrfCheck failed error on plugin endpoint.

Your GLPI setup information

Glpi 11.0.1 running in Ubuntu, Apache2, PHP8.4-Fpm,Mysql.

Anything else?

Headers are shown on top of plugin screens in the GLPI UI:

[cconard96]

While working with the GLPI11 beta release i was able tot disable the Csrf checking by adding the decorator: #[DisableCsrfChecks()] in the plugins controller

The attribute was removed because it is no longer needed. It seems to me that stateless endpoints, which don't use a session, should automatically skip CSRF checking now and plugins can register stateless URLs (See #20189).

I noticed GLPI uses the 'security_level: 0' param in its own routes

Are you talking about the HL API routes? This was the only place I saw that uses this parameter in a route attribute. The High-Level API does not use Symfony, but rather a custom routing solution. I did the HL API code before the work started on using Symfony routing for regular GLPI code and although I evaluating using Symfony for this case I did not believe it would be the right solution at the time.

Headers are shown on top of plugin screens in the GLPI UI

I haven't seen this.

[DonutsNL]

@cconard96 thanks for eachting out during your precious weekend :)

The presented solution...

function plugin_myplugin_boot() {
    SessionManager::registerPluginStatelessPath('myplugin', '#^/api/#');
}

should be added to the setup.php or hook.php?

I know that (because i allready tested it) calling SessionManager::registerPluginStatelessPath(PLUGIN_NAME, '#^/front/acs/#'); from setup.php > function plugin_init_samlsso() : void doesnt work. Presumably because its called after setting up the session.

Maybe, given the function name 'plugin_name_expl()' it seems it belongs in the hook.php as functions in the setup.php all have the plugin name in the end of the function names. xD Ill start in hook.php.

[cconard96]

should be added to the setup.php or hook.php?

I have no idea. Probably hook.php.

[DonutsNL]

The added function in hook.php is ignored. Adding the boot function to setup.php is being called and causes the following exception.

[2025-10-12 13:01:34] glpi.CRITICAL:   *** Uncaught PHP Exception Glpi\Exception\SessionExpiredException: "" at Session.php line 1068
  Backtrace :
  ./src/Session.php:1068
  ./src/Session.php:1182                             Session::checkValidSessionId()
  ./src/Glpi/Http/Firewall.php:144                   Session::checkLoginUser()
  ...trollerListener/FirewallStrategyListener.php:82 Glpi\Http\Firewall->applyStrategy()
  ...ymfony/event-dispatcher/EventDispatcher.php:260 Glpi\Kernel\Listener\ControllerListener\FirewallStrategyListener->onKernelController()
  ...ymfony/event-dispatcher/EventDispatcher.php:220 Symfony\Component\EventDispatcher\EventDispatcher::{closure:Symfony\Component\EventDispatcher\EventDispatcher::optimizeListeners():255}()
  ...symfony/event-dispatcher/EventDispatcher.php:56 Symfony\Component\EventDispatcher\EventDispatcher->callListeners()
  ./vendor/symfony/http-kernel/HttpKernel.php:169    Symfony\Component\EventDispatcher\EventDispatcher->dispatch()
  ./vendor/symfony/http-kernel/HttpKernel.php:76     Symfony\Component\HttpKernel\HttpKernel->handleRaw()
  ./vendor/symfony/http-kernel/Kernel.php:197        Symfony\Component\HttpKernel\HttpKernel->handle()
  ./public/index.php:70                              Symfony\Component\HttpKernel\Kernel->handle()

public static function checkValidSessionId()
    {
        global $DB;

        if (
            !isset($_SESSION['valid_id'])
            || ($_SESSION['valid_id'] !== session_id())
        ) {
            throw new SessionExpiredException();
        }

If i comment the new lines out from the setup.php I get the expected not allowed csrf error.

[DonutsNL]

The previous error was caused by a type safety error triggered in my script. It ending up in an invalid session error is not exactly what i was expecting :)

[github-actions]

This issue is closed and has been automatically locked. Please open a new issue with all requested information for related bugs.