Restore config backup on XG7100 gives "The configuration could not be restored"
-
That wouldn't normally happen with the config backup. Somehow that bit of JS snuck in there. We have seen 1-2 other reports of that but so far I don't think anyone here has managed to reproduce it. IIRC it was isolated to maybe one browser on one operating system (Safari, maybe?) but isn't hitting reliably enough that we can reproduce it and see what is happening.
If you take a new backup, does it also have that at the end? If so, what operating system and browser are you using?
-
Thanks for your response @jimp. Just tried it again and the
<script>tag is present only in full backup, partial backups are free of it.
Quite common combination of OS/Browser; Windows 10 Pro and Chrome 70.0.3538.77 -
Hmm, and it doesn't happen here with the same combination. Maybe a browser add-on (ad blocker, script blocker, password manager, etc), can you try starting without add-ons to see if it still happens?
Or try a different browser to see if it happens there as well.
-
Chrome keeps doing it in incognito mode and also when started with
--disable-extensions. Firefox 62.0 and Edge 17.17134 don't add the tag. -
Strange. I'm not seeing how that could end up in the file without it being based on the contents of the config. If that were the case, it would be in every copy not just from Chrome.
Just in case it is that, you can install the system patches package and try this little diff to see if it helps:
diff --git a/src/usr/local/www/diag_backup.php b/src/usr/local/www/diag_backup.php index fc141ac46b..e1977afe8a 100644 --- a/src/usr/local/www/diag_backup.php +++ b/src/usr/local/www/diag_backup.php @@ -164,6 +164,8 @@ if ($_POST) { } if (!$input_errors) { + /* Do not allow CSRF to alter the downloaded file */ + $GLOBALS['csrf']['rewrite'] = false; //$lockbckp = lock('config'); -
Applied the patch (verified it on the filesystem) but the download still contains the script tag.
-
I am seeing the same issue. I am running the latest version with windows 10 Pro 64bit and the version of chrome that I am running is Version 72.0.3626.96 (Official Build) (64-bit). Deleting the last line
<script type="text/javascript">CsrfMagic.end();</script>seem to fix the issue. Downloading the backup using IE, didn't have the
<script type="text/javascript">CsrfMagic.end();</script>appended to the end of the file.
I'm running the following version of pfsense:
2.4.5-DEVELOPMENT (amd64)
built on Wed Feb 06 14:15:42 EST 2019
FreeBSD 11.2-RELEASE-p8The hardware is Dell PowerEdge 410
-
@mikeisfly Can you reproduce that every time you download a backup in Chrome? What add-ons do you have installed?
It works fine for me here, but I have a patch you can try that might help. You can apply this with the system patches package.
0_1549567528356_backup-buffer-fix.diff
Apply that patch and try to take another backup in Chrome.
-
Sorry just now seeing this, I could with the old 2.4.4 version that I was running. I will try your patch as soon as I can. Right now I can not get to the backup and restore page due to a php error. I'm running
2.4.5-DEVELOPMENT (amd64)
built on Wed Feb 13 06:09:38 EST 2019
FreeBSD 11.2-RELEASE-p8Dashboard says this is the latest version.
packages I have installed are:acme, apcupsd, bind, frr, iperf, ladvd, LCDproc, nmap, ntopng, nut, openvpn-client-export, pfblockerNG, and routed.
-
I fixed the backup and restore by downloading the file from the master on Redmine. I'm still getting the javascript line appended to the config.xml before applying the patch. The patch worked, backups look good again.
Thanks!
