• v1.6.10 190f66ff6c

    emitlinks released this 2026-10-21 12:33:52 +00:00 | 59 commits to main since this release

    1.6.10 — CSRF / redirect fix for the settings page

    Symptom fixed: clicking Save on the plugin settings page redirected to glpi/front/central.php instead of saving.

    Root cause (verified against GLPI 11.0.11): GLPI's AccessErrorListener redirects to front/central.php when three conditions are met at once — a non-AJAX request, a failed CSRF check, and a URL carrying _redirected_from_profile_selector. All plugin forms shared one CSRF token (Session::getNewCSRFToken() reuses the session token), so submitting any one form consumed the token and every later submit on the same page failed the check.

    Changes:

    • Each form now gets its own standalone CSRF token (Session::getNewCSRFToken(true)), so saving one form no longer invalidates the others.
    • The submit handler rewrites form.action to strip _redirected_from_profile_selector, removing the only condition that turns an access error into a redirect to the home page.
    • Submissions remain AJAX (X-Requested-With: XMLHttpRequest + X-Glpi-Csrf-Token), which GLPI validates with preserve_token: true, so repeated saves keep working.
    • On failure the plugin shows an explicit error banner with a reload link instead of falling back to a native submit.

    Important after installing: GLPI marks a plugin as To update whenever its declared version changes. Until you click Mettre à jour in Administration > Plugins, the plugin is deactivated — its hooks are not loaded, the configuration menu is missing and its pages return 404.

    Verified on GLPI 11.0.11 (Docker, Apache 2.4.68): native POST with a fresh token → 200 and the config is written to glpi_plugin_airwatchsync_configs; a native POST with an already-consumed token and the profile-selector flag → 302 to front/central.php (the reported bug); the AJAX path used by the plugin → 200, token preserved, no redirect.

    Downloads