I started with the control panel server. Seemed to work fine. I did my first web server, then my dns server. When it did the DNS, now when I try to edit a dns zone, it reports "CSRF attempt blocked.". I have not pursued any further now, and am wondering how to get dns working again. Also, a general question in regards to upgrades - are there any articles on preserving customizations? For example, I like to keep my default TTL for dns records at 1800. Whenever I do an upgrade it changes to 86400 I believe. How many areas can we employ the "custom" file technique? Thanks,
Hi, could you compare if all files were updated correctly? If not then it might be that something is missing from the latest update and causing this issue. Regarding customization, to explain it in short: 1.) All files from /usr/local/ispconfig/server/conf and its subdirectories can be copied to the corresponding conf-custom location and altered there. If they exist, those files are used instead of those in conf. 2.) All files from install/tpl in the install package of ISPConfig can be copied to /usr/local/ispconfig/server/conf-custom/install/ and altered there. Those files are taken instead of the install templates on upgrades.
On the customization, great. Thanks. I'll check it out. About comparing the files, could you elaborate? I did a backup, so I could compare to that. Do you mean that or do you mean to the folder in /tmp that was extracted for install?
Just used the diff command on the server and interface folder found within the tar.gz folder. Nothing reported as different or existing only in /tmp. ?
To shed some light onto what Im finding (and calling it a night). I am using Nginx and PHP-FPM for my control panel. I may be incorrect but I suspect that $_POST is not getting set, and there for its not setting the csrf variables appropriately. I put an echo line within the function csrf_token_check() to try and output something. Its appearing like if(isset($_POST) && is_array($_POST)) {} is not even executing. I am confusing myself though too because on any other page where it has a form, it is posting just fine with present configuration. ??
Greets. Thanks for looking into that. I did also just figure out that its not just DNS - it is actually more things on the site. For example just tried to add a new client - blocked.
This is interesting : http://php.net/manual/en/reserved.variables.post.php Note that $_POST is NOT set for all HTTP POST operations, but only for specific types of POST operations. I have not been able to find documentation, but here's what I've found so far. $_POST _is_ set for: Content-Type: application/x-www-form-urlencoded In other words, for standard web forms. $_POST is NOT set for: Content-Type:text/xml A type used for a generic HTTP POST operation.
That's quite strange. ISPConfig uses Ajax requests that surely set _POST because _POST is used to get the form data.
Are you using a custom theme? Maybe that one has not been adapted to the latest security changes in ISPConfig. Please try the default theme and check if the errors are gone.
I am using a custom theme yes. I will try that. If that is the case, what changed? I'll need to modify my theme to suit.
I just visited the website for the theme (github) and there was a recent update to the theme for csrf specifically. Turns out there was two files that had a couple lines that needed to be added. Thanks for getting me going in the right direction!!!!!!!! :-D