-
AirWatch Sync 1.6.10 Stable
released this
2026-10-21 12:33:52 +00:00 | 59 commits to main since this release1.6.10 — CSRF / redirect fix for the settings page
Symptom fixed: clicking Save on the plugin settings page redirected to
glpi/front/central.phpinstead of saving.Root cause (verified against GLPI 11.0.11): GLPI's
AccessErrorListenerredirects tofront/central.phpwhen 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.actionto 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 withpreserve_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 tofront/central.php(the reported bug); the AJAX path used by the plugin → 200, token preserved, no redirect.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- Each form now gets its own standalone CSRF token (