Revert "Fixes broken file manager links."

[itsmerosu]

Reverts #214

This updated file manager has numerous bugs and appears poorly designed. I prefer to use my own file manager using https://www.monstaftp.com.

[greenreader9]

Was this tested? The filemanager instance you are trying to revert to does not work anymore.

[itsmerosu]

Was this tested? The filemanager instance you are trying to revert to does not work anymore.

Yeah, as I already mentioned, I created my own file manager similar to the old Filemanager.io, but with a higher upload limit of up to 512 MB and without errors, using the same code base that ByetHost used to build Filemanager.io (https://www.monstaftp.com).

[greenreader9]

The filemanager URL you proposed is no longer functioning. The filemanager URL should stay with an iFN controlled link due to security and availability concerns.

[itsmerosu]

The filemanager URL you proposed is no longer functioning. The filemanager URL should stay with an iFN controlled link due to security and availability concerns.

This file manager instance is no longer functioning.

As I mentioned, we don’t need to rely on Filemanager.io or Filemanager.io/v3 to manage our FTP accounts and files. We can build our own file manager. I don’t dislike the v3 file manager provided by ByetHost, but it has bugs, and the UI is not ideal.

As contributors, we don’t need to change the original XERA files. Instead, we can develop XERA’s own file manager similar to the old version, with a higher upload limit (up to 512 MB) and without errors, and integrate it into:
$link = "https://xerafilemanager/new/#/c/ftpupload.net/$username/$config";

[greenreader9]

Unresolved

Sure, you could develop your own file manager or host your own version of Monsta. However that's not the problem. The problem is that you are trying to hardcode a file manager URL into the code that is non-functional.

[greenreader9]

Sure, you could develop your own file manager or host your own version of Monsta. However that's not the problem. The problem is that you are trying to hardcode a file manager URL into the code that is non-functional.

[itsmerosu]

Unresolved

Sure, you could develop your own file manager or host your own version of Monsta. However that's not the problem. The problem is that you are trying to hardcode a file manager URL into the code that is non-functional.

Sure, you could develop your own file manager or host your own version of Monsta. However that's not the problem. The problem is that you are trying to hardcode a file manager URL into the code that is non-functional.

I’m not referring to the old file manager URL. I know, and everyone knows, that the old URL was changed and is no longer functional.

What I’m suggesting is to revert the new v3 update that Mr. @MrRamyg pushed, and @mahtab2003 merged into the dev repo. The new version has bugs and a poor UI, and many users are not satisfied with it. After reverting that push, the previous stable code will return to the original XERA repo. Once that happens, we can update the file manager URL with a fully functional one for XERA’s own file manager.

By the way, I have already tested it, and users are happy with it and are actively using it.

Of course, @mahtab2003 @santydesignscr can decide as they prefer. I’m simply offering a suggestion based on user feedback and stability.

[greenreader9]

Unless I am missing something (and please tell me if I am), you are hardcoding a non functional file manager URL into the create_fm_link() function. If your plan is to rollback these changes and then update with a working URL, that would leave users with a broken system while the new file manager is being developed.

Sure the new file manager is not the best, but it works. If you want to integrate a new file manager, please add that to this pull request as well, instead of only rolling back to a broken version of the code and hoping someone else fixes the problem later.

[itsmerosu]

Unless I am missing something (and please tell me if I am), you are hardcoding a non functional file manager URL into the create_fm_link() function. If your plan is to rollback these changes and then update with a working URL, that would leave users with a broken system while the new file manager is being developed.

Sure the new file manager is not the best, but it works. If you want to integrate a new file manager, please add that to this pull request as well, instead of only rolling back to a broken version of the code and hoping someone else fixes the problem later.

Before my push, @mahtab2003 merged @MrRamyg ’s update, which replaced the functionality with the new file manager and created the create_fm_link() function. That new file manager update introduced bugs and UI issues, which users are complaining about.

My request to revert is not intended to restore a broken version. The goal is to roll back only the buggy changes introduced in v3, so that the repository returns to the last stable state with the old file manager.

Once reverted, I will push the working XERA file manager functionality (which @santydesignscr and I have already tested). I am not expecting someone else to fix it later. I am ready to integrate the working file manager immediately after the revert.

So the process is:

1. Revert the buggy v3 merge (to restore the last stable, functional version).
2. Push the working XERA file manager functionality.

This will ensure that users do not face a broken system at any point.

[hclis]

Reverts #214

This updated file manager has numerous bugs and appears poorly designed. I prefer to use my own file manager using https://www.monstaftp.com.

Didn't they use AI to build it? Overall it looks like it's made by AI, and then if you view it's source code, these comments say it all:

•     /*  - Modern File Manager */
  

•     /* Default to dark theme */
  

•     <!-- TinyMCE Editor (Self-hosted) -->
  

•     // Security: Block developer tools while preserving file manager functionality
  

•    // Allow all developer tools when debug=1 is in URL
  

[hclis]

If you don't have a solution, i recently found one. Took some time but using this on my user dashboard. Works perfectly anywhere, i have two mofh sites and i simply just change db and cpanel url.

<?php
session_start();
error_reporting(E_ALL);
ini_set('display_errors', 1);

$db_host = 'DATA_REDACTED';
$db_name = 'DATA_REDACTED';
$db_user = 'DATA_REDACTED';
$db_pass = 'DATA_REDACTED';

try {
    $pdo = new PDO("mysql:host=$db_host;dbname=$db_name", $db_user, $db_pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
    die("An err occured: " . $e->getMessage());
}

$cookie_id = $_COOKIE['session_id'] ?? null;
$logged_in = false;
$user_data = null;

if ($cookie_id) {
    $stmt = $pdo->prepare("SELECT * FROM users WHERE session_id = ? LIMIT 1");
    $stmt->execute([$cookie_id]);
    $user_data = $stmt->fetch(PDO::FETCH_ASSOC);

    if ($user_data) {
        $logged_in = true;
        $vpuser = $user_data['vpuser'];
        $vppass = $user_data['vppass'];
    }
}

// redirect to chlogin
if (!$logged_in || !$user_data) {
    header("Location: https://host.celestei.com/account/login");
    exit;
}


$loginUrl = "https://cpanel.host.celestei.com/login.php";
$postData = [
    "uname" => $vpuser,
    "passwd" => $vppass,
    "login" => "Login"
];

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $loginUrl);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($postData));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);
curl_setopt($ch, CURLOPT_COOKIEJAR, 'cookiejar.txt');
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36");
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

$response = curl_exec($ch);
curl_close($ch);


$mainPanelUrl = "https://cpanel.host.celestei.com/panel/indexpl.php";

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $mainPanelUrl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_COOKIEFILE, 'cookiejar.txt');
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36");
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

$panelContent = curl_exec($ch);
curl_close($ch);

if (file_exists('cookiejar.txt')) {
    unlink('cookiejar.txt');
}

$filemanager_url = "";

if (preg_match('/https:\/\/filemanager\.ai\/new3\/index\.php\?u=[^&]+&p=[^"\' ]+/i', $panelContent, $matches)) {
    $filemanager_url = $matches[0];
}

if (!empty($filemanager_url)) {
    header("Location: " . $filemanager_url);
    exit;
} else {
    if (preg_match('/https:\/\/filemanager\.ai[^"\' ]+/i', $panelContent, $matches)) {
        $filemanager_url = $matches[0];
        header("Location: " . $filemanager_url);
        exit;
    } else {
        // if ftp link not found fallback to actual cp li
        header("Location: https://cpanel.host.celestei.com/panel/indexpl.php");
        exit;
    }
}
?> 

[itsmerosu]

Reverts #214
This updated file manager has numerous bugs and appears poorly designed. I prefer to use my own file manager using https://www.monstaftp.com.

Didn't they use AI to build it? Overall it looks like it's made by AI, and then if you view it's source code, these comments say it all:

•     /*  - Modern File Manager */
  

•     /* Default to dark theme */
  

•     <!-- TinyMCE Editor (Self-hosted) -->
  

•     // Security: Block developer tools while preserving file manager functionality
  

•    // Allow all developer tools when debug=1 is in URL
  

If you don't have a solution, i recently found one. Took some time but using this on my user dashboard. Works perfectly anywhere, i have two mofh sites and i simply just change db and cpanel url.

<?php
session_start();
error_reporting(E_ALL);
ini_set('display_errors', 1);

$db_host = 'DATA_REDACTED';
$db_name = 'DATA_REDACTED';
$db_user = 'DATA_REDACTED';
$db_pass = 'DATA_REDACTED';

try {
    $pdo = new PDO("mysql:host=$db_host;dbname=$db_name", $db_user, $db_pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
    die("An err occured: " . $e->getMessage());
}

$cookie_id = $_COOKIE['session_id'] ?? null;
$logged_in = false;
$user_data = null;

if ($cookie_id) {
    $stmt = $pdo->prepare("SELECT * FROM users WHERE session_id = ? LIMIT 1");
    $stmt->execute([$cookie_id]);
    $user_data = $stmt->fetch(PDO::FETCH_ASSOC);

    if ($user_data) {
        $logged_in = true;
        $vpuser = $user_data['vpuser'];
        $vppass = $user_data['vppass'];
    }
}

// redirect to chlogin
if (!$logged_in || !$user_data) {
    header("Location: https://host.celestei.com/account/login");
    exit;
}


$loginUrl = "https://cpanel.host.celestei.com/login.php";
$postData = [
    "uname" => $vpuser,
    "passwd" => $vppass,
    "login" => "Login"
];

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $loginUrl);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($postData));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);
curl_setopt($ch, CURLOPT_COOKIEJAR, 'cookiejar.txt');
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36");
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

$response = curl_exec($ch);
curl_close($ch);


$mainPanelUrl = "https://cpanel.host.celestei.com/panel/indexpl.php";

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $mainPanelUrl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_COOKIEFILE, 'cookiejar.txt');
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36");
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

$panelContent = curl_exec($ch);
curl_close($ch);

if (file_exists('cookiejar.txt')) {
    unlink('cookiejar.txt');
}

$filemanager_url = "";

if (preg_match('/https:\/\/filemanager\.ai\/new3\/index\.php\?u=[^&]+&p=[^"\' ]+/i', $panelContent, $matches)) {
    $filemanager_url = $matches[0];
}

if (!empty($filemanager_url)) {
    header("Location: " . $filemanager_url);
    exit;
} else {
    if (preg_match('/https:\/\/filemanager\.ai[^"\' ]+/i', $panelContent, $matches)) {
        $filemanager_url = $matches[0];
        header("Location: " . $filemanager_url);
        exit;
    } else {
        // if ftp link not found fallback to actual cp li
        header("Location: https://cpanel.host.celestei.com/panel/indexpl.php");
        exit;
    }
}
?> 

Hi,

There are many issues with the provided PHP auto-login script.

• Plain-text cPanel usernames and passwords are stored and used directly in the script, which is a serious security risk if the database or logs are compromised.
• cPanel credentials are transmitted during login and later exposed through File Manager auto-login URLs, making them visible in browser history, logs, and referrer headers.
• SSL certificate verification is disabled in all cURL requests, which allows man-in-the-middle attacks and credential interception.
• A single static cookie file (cookiejar.txt) is used for all users, which can cause session collision and unauthorised access when multiple users access the system at the same time**.
• The script does not verify whether the external cPanel login request was successful before proceeding to the next step.
• Authentication depends solely on a cookie-based session ID without regeneration, expiration checks, or additional validation, creating a session fixation risk.
• There is no session expiration mechanism, meaning old or leaked session IDs may remain valid indefinitely.
• The script does not check user role, hosting status, or account state before granting File Manager access.
• File Manager URLs are extracted by parsing HTML content using regular expressions, which is fragile and may break if the external panel layout changes.
• External URLs for the control panel and File Manager are hard-coded, reducing flexibility and making future maintenance or migration more difficult.
• PHP error display is enabled, which may expose sensitive system information in a production environment.
• cURL requests do not define timeout values, which can cause the application to hang if the external service is slow or unavailable.
• The database connection does not explicitly define a character set, which may lead to encoding or security issues.

Overall, while the script functions as intended, the current implementation presents high security and stability risks and is not recommended for production use without significant changes.

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[greenreader9]

Hi,

There are many issues with the provided PHP auto-login script.

• Plain-text cPanel usernames and passwords are stored and used directly in the script, which is a serious security risk if the database or logs are compromised.

• cPanel credentials are transmitted during login and later exposed through File Manager auto-login URLs, making them visible in browser history, logs, and referrer headers.

• SSL certificate verification is disabled in all cURL requests, which allows man-in-the-middle attacks and credential interception.

• A single static cookie file (cookiejar.txt) is used for all users, which can cause session collision and unauthorised access when multiple users access the system at the same time**.

• The script does not verify whether the external cPanel login request was successful before proceeding to the next step.

• Authentication depends solely on a cookie-based session ID without regeneration, expiration checks, or additional validation, creating a session fixation risk.

• There is no session expiration mechanism, meaning old or leaked session IDs may remain valid indefinitely.

• The script does not check user role, hosting status, or account state before granting File Manager access.

• File Manager URLs are extracted by parsing HTML content using regular expressions, which is fragile and may break if the external panel layout changes.

• External URLs for the control panel and File Manager are hard-coded, reducing flexibility and making future maintenance or migration more difficult.

• PHP error display is enabled, which may expose sensitive system information in a production environment.

• cURL requests do not define timeout values, which can cause the application to hang if the external service is slow or unavailable.

• The database connection does not explicitly define a character set, which may lead to encoding or security issues.

Overall, while the script functions as intended, the current implementation presents high security and stability risks and is not recommended for production use without significant changes.

Why are you using AI to review code and not checking what it spits out? The code that was shared is perfectly valid as an example/PoC.

In any case, I think there needs to be code to provide a working file manager in the same PR that is trying to change the UI that leads to it.

There should not be separate PRs to add in a new filemanager.

Can you add the code for your new filemanager to this PR @itsmerosu ?

[greenreader9]

If you don't have a solution, i recently found one. Took some time but using this on my user dashboard. Works perfectly anywhere, i have two mofh sites and i simply just change db and cpanel url.

I agree this should work, however it is much cleaner to reverse engineer how the URL is built instead. This improves time and reduces server resources by eliminating multiple cURL calls on each cf page load. I have not taken a good look at the new URL format, but it may be worth comparing to the old format, or asking iFN how it is built.

[itsmerosu]

Hi,
There are many issues with the provided PHP auto-login script.

• Plain-text cPanel usernames and passwords are stored and used directly in the script, which is a serious security risk if the database or logs are compromised.
• cPanel credentials are transmitted during login and later exposed through File Manager auto-login URLs, making them visible in browser history, logs, and referrer headers.
• SSL certificate verification is disabled in all cURL requests, which allows man-in-the-middle attacks and credential interception.
• A single static cookie file (cookiejar.txt) is used for all users, which can cause session collision and unauthorised access when multiple users access the system at the same time**.
• The script does not verify whether the external cPanel login request was successful before proceeding to the next step.
• Authentication depends solely on a cookie-based session ID without regeneration, expiration checks, or additional validation, creating a session fixation risk.
• There is no session expiration mechanism, meaning old or leaked session IDs may remain valid indefinitely.
• The script does not check user role, hosting status, or account state before granting File Manager access.
• File Manager URLs are extracted by parsing HTML content using regular expressions, which is fragile and may break if the external panel layout changes.
• External URLs for the control panel and File Manager are hard-coded, reducing flexibility and making future maintenance or migration more difficult.
• PHP error display is enabled, which may expose sensitive system information in a production environment.
• cURL requests do not define timeout values, which can cause the application to hang if the external service is slow or unavailable.
• The database connection does not explicitly define a character set, which may lead to encoding or security issues.

Overall, while the script functions as intended, the current implementation presents high security and stability risks and is not recommended for production use without significant changes.

Why are you using AI to review code and not checking what it spits out? The code that was shared is perfectly valid as an example/PoC.

In any case, I think there needs to be code to provide a working file manager in the same PR that is trying to change the UI that leads to it.

There should not be separate PRs to add in a new filemanager.

Can you add the code for your new filemanager to this PR @itsmerosu ?

Yes, I have already done that.

At the moment, I am waiting for a new push from @santydesignscr , as discussed the day before yesterday.

Once that is received, I will push an updated version of the code with a fully working file manager.

For your information, I have already tested this on my own Xera dashboard.

However, I did not want to share that URL on a public domain.

Therefore, I created a separate Xera file manager on a different domain.

I am currently waiting for the new push so I can proceed with the update.

[AgentDeath532]

So why are we replacing this with a random 3rd party service? I don't really care much as I don't use MOFH anymore but this goes against almost every single recommendation in existence

[itsmerosu]

So why are we replacing this with a random 3rd party service? I don't really care much as I don't use MOFH anymore but this goes against almost every single recommendation in existence

Please read all the comments so you can understand why we are discussing this topic.

[SpookyKipper]

So you are saying you prefer a broken file manager rather than a working but buggy one?

You keep saying you will push a working one, but why do you have to do that only AFTER this is merged?
You need to have it up and running first for us to even consider merging this, which is highly unlikely tbh.

[itsmerosu]

So you are saying you prefer a broken file manager rather than a working but buggy one?

You keep saying you will push a working one, but why do you have to do that only AFTER this is merged? You need to have it up and running first for us to even consider merging this, which is highly unlikely tbh.

@santydesignscr is currently working on his own project, as we discussed in our last conversation. I am not pushing any updated code because @santydesignscr and @mahtab2003 are busy with their own projects. Additionally, there are several pending pull requests, which is another reason I'm not pushing any new updates to the development repository.

[SpookyKipper]

I'm not pushing any new updates to the development repository.

Good, close this PR and be done with it. Nobody involved in this PR except you welcome this change.

BTW, I think you keep tagging them is actually disturbing their "busy with their own projects."

[itsmerosu]

Good, close this PR and be done with it. Nobody involved in this PR except you welcome this change.

Bruh, in your language, it's you who came here, left comments, and involved yourself. You can unsubscribe from notifications if other suggestions are bothering you. Also, if you are reading this, this request where you're commenting is not an 'Add' request. This is a "revert" request, so I don't want to misconfigure the original code. That's why I waited for this revert request approval. After approval, all merged code will be changed in the original, and then I will push those changes to the dev repository. So I replied, "I'm not pushing any new updates to the development repository." Please read all suggestions (comments) before providing your own.

And lastly, if my request is not acceptable, then authors can reject it anytime. I respect your and others' suggestions, but this is not a tone of suggestion, so I reply in the same tone. Sorry about that.

[SpookyKipper]

it's you who came here, left comments, and involved yourself. You can unsubscribe from notifications

I am not sure where did you get that I am being disturbed? I mentioned "they" and "their" which clearly means the two people that has full access to the repo. I guess you are the one who needs to read everything thoroughly, not me.

a "revert" request

I am not sure why do you make this request? Your code is not going to benefit anyone anyways (Read below)

I don't want to misconfigure the original code

You quite literally already did by hardcoding a file manager URL that is not working. It does not matter if you "make it later," that filemanager.ai URL is not going to work no matter what, because you dont have access to its server!

This issue has been raised up multiple times above, and you are reluctant to provide a viable solution, but instead reply with AI bs

this is not a tone of suggestion

Sure, that is not quite a solution apart from telling you to close it.

So here is my view and suggestions on how your PR should be implemented: (assuming using MonstaFTP instance)

Since iFastNet does not provide it anymore, the only "secure" and "trusted" way is for the MOFH reseller to host it themselves, so there will need to be a new field in the admin panel for the reseller to set their own file manager URL, instead of hardcoding one that is not even going to work anyways.

If you would like to revert it to MonstaFTP, please, in this PR:

1. Do the above by making a new field in the database and admin UI & backend code
2. Re-instate the MonstaFTP code (you have done this already except the hardcoded URL part which should be changed)
3. Do not remove Byet's new filemanager opening code, as a MonstaFTP license is not cheap, and some resellers may not want to pay for that, and would prefer to use Byet's solution.
4. Add another field in the database and admin UI & backend for allowing the reseller to switch between MonstaFTP and Byet's filemanager.

You may disagree with keeping the Byet filemanager part, but that is the current only solution from iFastNet officially, and I do think it should be kept as an option.

[itsmerosu]

it's you who came here, left comments, and involved yourself. You can unsubscribe from notifications

I am not sure where did you get that I am being disturbed? I mentioned "they" and "their" which clearly means the two people that has full access to the repo. I guess you are the one who needs to read everything thoroughly, not me.

a "revert" request

I am not sure why do you make this request? Your code is not going to benefit anyone anyways (Read below)

I don't want to misconfigure the original code

You quite literally already did by hardcoding a file manager URL that is not working. It does not matter if you "make it later," that filemanager.ai URL is not going to work no matter what, because you dont have access to its server!

This issue has been raised up multiple times above, and you are reluctant to provide a viable solution, but instead reply with AI bs

this is not a tone of suggestion

Sure, that is not quite a solution apart from telling you to close it.

So here is my view and suggestions on how your PR should be implemented: (assuming using MonstaFTP instance)

Since iFastNet does not provide it anymore, the only "secure" and "trusted" way is for the MOFH reseller to host it themselves, so there will need to be a new field in the admin panel for the reseller to set their own file manager URL, instead of hardcoding one that is not even going to work anyways.

If you would like to revert it to MonstaFTP, please, in this PR:

1. Do the above by making a new field in the database and admin UI & backend code
2. Re-instate the MonstaFTP code (you have done this already except the hardcoded URL part which should be changed)
3. Do not remove Byet's new filemanager opening code, as a MonstaFTP license is not cheap, and some resellers may not want to pay for that, and would prefer to use Byet's solution.
4. Add another field in the database and admin UI & backend for allowing the reseller to switch between MonstaFTP and Byet's filemanager.

You may disagree with keeping the Byet filemanager part, but that is the current only solution from iFastNet officially, and I do think it should be kept as an option.

I appreciate that you pointed out several aspects that others may have overlooked. I will refrain from making further comments on this topic. The author has decided to proceed as they wish, and I respect all suggestions regarding this revent request. Thank you to everyone who took the time to review and provide feedback.

[hclis]

Hi,
There are many issues with the provided PHP auto-login script.

• Plain-text cPanel usernames and passwords are stored and used directly in the script, which is a serious security risk if the database or logs are compromised.
• cPanel credentials are transmitted during login and later exposed through File Manager auto-login URLs, making them visible in browser history, logs, and referrer headers.
• SSL certificate verification is disabled in all cURL requests, which allows man-in-the-middle attacks and credential interception.
• A single static cookie file (cookiejar.txt) is used for all users, which can cause session collision and unauthorised access when multiple users access the system at the same time**.
• The script does not verify whether the external cPanel login request was successful before proceeding to the next step.
• Authentication depends solely on a cookie-based session ID without regeneration, expiration checks, or additional validation, creating a session fixation risk.
• There is no session expiration mechanism, meaning old or leaked session IDs may remain valid indefinitely.
• The script does not check user role, hosting status, or account state before granting File Manager access.
• File Manager URLs are extracted by parsing HTML content using regular expressions, which is fragile and may break if the external panel layout changes.
• External URLs for the control panel and File Manager are hard-coded, reducing flexibility and making future maintenance or migration more difficult.
• PHP error display is enabled, which may expose sensitive system information in a production environment.
• cURL requests do not define timeout values, which can cause the application to hang if the external service is slow or unavailable.
• The database connection does not explicitly define a character set, which may lead to encoding or security issues.

Overall, while the script functions as intended, the current implementation presents high security and stability risks and is not recommended for production use without significant changes.

Why are you using AI to review code and not checking what it spits out? The code that was shared is perfectly valid as an example/PoC.
In any case, I think there needs to be code to provide a working file manager in the same PR that is trying to change the UI that leads to it.
There should not be separate PRs to add in a new filemanager.
Can you add the code for your new filemanager to this PR @itsmerosu ?

Yes, I have already done that.

At the moment, I am waiting for a new push from @santydesignscr , as discussed the day before yesterday.

Once that is received, I will push an updated version of the code with a fully working file manager.

For your information, I have already tested this on my own Xera dashboard.

However, I did not want to share that URL on a public domain.

Therefore, I created a separate Xera file manager on a different domain.

I am currently waiting for the new push so I can proceed with the update.

I know. That was a small one i created when i had spare time. I'm thinking of creating a more secure one soon, but if you don't mind me asking what is your solution to the new File Manager? I need to inspire myself because all i can think of is pulling it from the database without the need for the Url.

[hclis]

If you don't have a solution, i recently found one. Took some time but using this on my user dashboard. Works perfectly anywhere, i have two mofh sites and i simply just change db and cpanel url.

I agree this should work, however it is much cleaner to reverse engineer how the URL is built instead. This improves time and reduces server resources by eliminating multiple cURL calls on each cf page load. I have not taken a good look at the new URL format, but it may be worth comparing to the old format, or asking iFN how it is built.

I am pretty sure they encrypted it with their own encryption, e.g hex/binary put into url-safe base64. I haven't tried decoding it yet, and not sure it's a commonly known type of encryption.