[GH-ISSUE #1282] "Invalid Token" Error When Saving Files in TinyFileManager v2.6 #825

New issue

Open

opened 2026-03-02 16:01:39 +03:00 by kerem · 3 comments

kerem commented

2026-03-02 16:01:39 +03:00

Owner

Originally created by @smalos on GitHub (Feb 14, 2025).
Original GitHub issue: https://github.com/prasathmani/tinyfilemanager/issues/1282

I'm encountering an issue with TinyFileManager v2.6. Logging in and opening files work as expected, but attempting to save a file results in an "Invalid Token" error. This issue did not occur in version 2.4.7.

Configuration Details:

I am using the following configuration:

define('FM_EMBED', true);
define('FM_SELF_URL', $_SERVER['PHP_SELF']);

To debug, I added a simple logMessage() function to log the CSRF token. I observed that the token changes with every action in TFM, which might be expected behavior.

Here’s the relevant section of the code:

// Generating CSRF Token
if (empty($_SESSION['token'])) {
    if (function_exists('random_bytes')) {
        $_SESSION['token'] = bin2hex(random_bytes(32));
    } else {
        $_SESSION['token'] = bin2hex(openssl_random_pseudo_bytes(32));
    }
    logMessage($_SESSION['token']);  // log token to a text file
}

However, the verifyToken() function fails, meaning:

hash_equals($_SESSION['token'], $token)

returns false.

Observations:

It seems like the CSRF token is not being correctly passed to the server before saving the file.
The issue is new in v2.6—it did not occur in v2.4.7.
Every action in TinyFileManager seems to generate a new token.

Expected Behavior:

Saving a file should not trigger an "Invalid Token" error if the session token is valid.

Any insights on why hash_equals($_SESSION['token'], $token) fails in v2.6 but worked in v2.4.7 would be greatly appreciated.
Could this be related to FM_EMBED mode, or has there been a change in how CSRF tokens are handled?

Originally created by @smalos on GitHub (Feb 14, 2025). Original GitHub issue: https://github.com/prasathmani/tinyfilemanager/issues/1282 I'm encountering an issue with TinyFileManager v2.6. Logging in and opening files work as expected, but attempting to save a file results in an "Invalid Token" error. This issue did not occur in version 2.4.7. **Configuration Details:** I am using the following configuration: ``` define('FM_EMBED', true); define('FM_SELF_URL', $_SERVER['PHP_SELF']); ``` To debug, I added a simple logMessage() function to log the CSRF token. I observed that the token changes with every action in TFM, which might be expected behavior. Here’s the relevant section of the code: ``` // Generating CSRF Token if (empty($_SESSION['token'])) { if (function_exists('random_bytes')) { $_SESSION['token'] = bin2hex(random_bytes(32)); } else { $_SESSION['token'] = bin2hex(openssl_random_pseudo_bytes(32)); } logMessage($_SESSION['token']); // log token to a text file } ``` However, the verifyToken() function fails, meaning: `hash_equals($_SESSION['token'], $token)` returns false. **Observations:** It seems like the CSRF token is not being correctly passed to the server before saving the file. The issue is new in v2.6—it did not occur in v2.4.7. Every action in TinyFileManager seems to generate a new token. **Expected Behavior:** Saving a file should not trigger an "Invalid Token" error if the session token is valid. Any insights on why hash_equals($_SESSION['token'], $token) fails in v2.6 but worked in v2.4.7 would be greatly appreciated. Could this be related to FM_EMBED mode, or has there been a change in how CSRF tokens are handled?

kerem commented

2026-03-02 16:01:40 +03:00

Author

Owner

@prasathmani commented on GitHub (Feb 14, 2025):

thanks for reporting, i'll check it out.

@prasathmani commented on GitHub (Feb 14, 2025): thanks for reporting, i'll check it out.

kerem commented

2026-03-02 16:01:40 +03:00

Author

Owner

@smalos commented on GitHub (Feb 15, 2025):

I think the issue lies here: For FM_EMBED, no session is created as far as I have seen, which is why the token is generated again and again with every click:

//Generating CSRF Token
if (empty($_SESSION['token'])) {

As a quick test has shown, the aforementioned error is no longer displayed if a session is also started for FM_EMBED.
(There might be other ways to solve the issue of course)

if (defined('FM_EMBED')) {
    $use_auth = false;
    $sticky_navbar = false;

    if (session_status() == PHP_SESSION_NONE) {
        session_start();
    }
}

But I’m not sure why the whole session initialization block is omitted at all for FM_EMBED here:

else { 
    @set_time_limit(600);

    date_default_timezone_set($default_timezone);
   // ...

@smalos commented on GitHub (Feb 15, 2025): I think the issue lies here: For FM_EMBED, no session is created as far as I have seen, which is why the token is generated again and again with every click: ``` //Generating CSRF Token if (empty($_SESSION['token'])) { ``` As a quick test has shown, the aforementioned error is no longer displayed if a session is also started for FM_EMBED. (There might be other ways to solve the issue of course) ``` if (defined('FM_EMBED')) { $use_auth = false; $sticky_navbar = false; if (session_status() == PHP_SESSION_NONE) { session_start(); } } ``` But I’m not sure why the whole session initialization block is omitted at all for FM_EMBED here: ``` else { @set_time_limit(600); date_default_timezone_set($default_timezone); // ... ```

kerem commented

2026-03-02 16:01:40 +03:00

Author

Owner

@smalos commented on GitHub (Feb 24, 2025):

Is there any reason not to use sessions in embedded mode as well? Someone probably once decided they weren't needed.

@smalos commented on GitHub (Feb 24, 2025): Is there any reason not to use sessions in embedded mode as well? Someone probably once decided they weren't needed.