Timezone issue v8.2.1
Permalink
I have built a new website using V8.2.1.
Now when I try to edit a block on a page I an getting ACcess denied. I have tracked this down to the timezone issue,
This even affects access to the dashboard.
When I first login as the admin I have access to the dashnoard
If I return to the site to access a page and then try to get to the dashboard again, or try to edit a block on the page I get a 500 error Access Denied in the logs.For the dashboard the slide-in is a blank grey.
When I installed the website the timezone in php.ini was set to Greenwich Mean Time (UTC). I have now removed that from php.ini and installed a second website which seems to be ok.
I believe the issue is that there is a 1 hour difference between the time the edit token is created and then when a save is tried even if I edit and save the change in seconds.
I have done all of the obvious checks and even compared the timezone settings between the two websites on the server. As far as I can tell everything looks fine but the first website continues to throw 500 ACcess denied errors.
The error in the logs is
Exception Occurred: /var/www/vhosts/xxxx.org/httpdocs/concrete/controllers/backend/user_interface/page.php:29 Access Denied (0)
Any ideas most welcome. What is driving me crazy this is the first time I have had this issue in the 20 or so 8.2.1 websites I have built this year.
Thanks
Martyn
c5 environmental values.
# concrete5 Version
Core Version - 8.2.1
Version Installed - 8.2.1
Database Version - 20170802000000
# concrete5 Packages
Cookies Notice (1.3.1), Cycle2 Slide Show (1.0.2), Simple Gallery (1.0.5), Stucco (2.1.3), Thumb Gallery (1.0.3), Vimeo Video (1.0.2), Vivid Carousel (1.0.1), Webli Content PopUp (2.0)
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - On
Overrides Cache - On
Full Page Caching - On - If blocks on the particular page allow it.
Full Page Cache Lifetime - Every 6 hours (default setting).
# Server Software
nginx/1.10.3
# Server API
fpm-fcgi
# PHP Version
7.0.22-0ubuntu0.16.04.1
# PHP Extensions
calendar, cgi-fcgi, Core, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imagick, imap, intl, json, libxml, mbstring, mcrypt, memcache, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, pspell, readline, recode, Reflection, session, shmop, SimpleXML, sockets, SPL, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend OPcache, zip, zlib
# PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 1000
memory_limit - 128M
post_max_size - 8M
sql.safe_mode - Off
upload_max_filesize - 2M
memcache.max_failover_attempts - 20
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
opcache.max_accelerated_files - 2000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5
Now when I try to edit a block on a page I an getting ACcess denied. I have tracked this down to the timezone issue,
This even affects access to the dashboard.
When I first login as the admin I have access to the dashnoard
If I return to the site to access a page and then try to get to the dashboard again, or try to edit a block on the page I get a 500 error Access Denied in the logs.For the dashboard the slide-in is a blank grey.
When I installed the website the timezone in php.ini was set to Greenwich Mean Time (UTC). I have now removed that from php.ini and installed a second website which seems to be ok.
I believe the issue is that there is a 1 hour difference between the time the edit token is created and then when a save is tried even if I edit and save the change in seconds.
I have done all of the obvious checks and even compared the timezone settings between the two websites on the server. As far as I can tell everything looks fine but the first website continues to throw 500 ACcess denied errors.
The error in the logs is
Exception Occurred: /var/www/vhosts/xxxx.org/httpdocs/concrete/controllers/backend/user_interface/page.php:29 Access Denied (0)
Any ideas most welcome. What is driving me crazy this is the first time I have had this issue in the 20 or so 8.2.1 websites I have built this year.
Thanks
Martyn
c5 environmental values.
# concrete5 Version
Core Version - 8.2.1
Version Installed - 8.2.1
Database Version - 20170802000000
# concrete5 Packages
Cookies Notice (1.3.1), Cycle2 Slide Show (1.0.2), Simple Gallery (1.0.5), Stucco (2.1.3), Thumb Gallery (1.0.3), Vimeo Video (1.0.2), Vivid Carousel (1.0.1), Webli Content PopUp (2.0)
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - On
Overrides Cache - On
Full Page Caching - On - If blocks on the particular page allow it.
Full Page Cache Lifetime - Every 6 hours (default setting).
# Server Software
nginx/1.10.3
# Server API
fpm-fcgi
# PHP Version
7.0.22-0ubuntu0.16.04.1
# PHP Extensions
calendar, cgi-fcgi, Core, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imagick, imap, intl, json, libxml, mbstring, mcrypt, memcache, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, pspell, readline, recode, Reflection, session, shmop, SimpleXML, sockets, SPL, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend OPcache, zip, zlib
# PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 1000
memory_limit - 128M
post_max_size - 8M
sql.safe_mode - Off
upload_max_filesize - 2M
memcache.max_failover_attempts - 20
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
opcache.max_accelerated_files - 2000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5
Your token theory is interesting but I don't think that's the problem. Tokens have a lifespan of 24 hours if memory serves so an hour difference wouldn't make a difference.
Thats a fair point, but I am at a loss to explain anything else as a cause.
I installed a second website on the same server lastnight as a clean install and it is behaving correctly as expected.
I took a db and code copy of the troublesome site and put it onto my dev environment which I have been using for over a year and it is still exhibiting the same issue.
My only remaining option now is to rebuild the live site from scratch to see if that breaks.
But I am open to other ideas.
Thanks
Martyn
I installed a second website on the same server lastnight as a clean install and it is behaving correctly as expected.
I took a db and code copy of the troublesome site and put it onto my dev environment which I have been using for over a year and it is still exhibiting the same issue.
My only remaining option now is to rebuild the live site from scratch to see if that breaks.
But I am open to other ideas.
Thanks
Martyn
I might have an explanation. I saw something a bit like this not long ago on another site. For some reasons, some files in the concrete folder had their permissions all messed up.
Maybe you could check that file using an FTP client and see what kind of permissions are set on it.
In that other case, it was even weirder as I wasn't able to modify the permissions, I had to delete the files and re-upload them again.
Maybe you could check that file using an FTP client and see what kind of permissions are set on it.
In that other case, it was even weirder as I wasn't able to modify the permissions, I had to delete the files and re-upload them again.
I have applied to one directory below the webroot :-
chown -R www-data:www-data *
chmod -R 775 *
This is what I usually apply until the project is complete then also
chmod -R 664 to all the folders
Still no change
chown -R www-data:www-data *
chmod -R 775 *
This is what I usually apply until the project is complete then also
chmod -R 664 to all the folders
Still no change
I strongly suggest you check that file specifically. Like I said, in my case, I tried that as well and it didn't work. I really had to go to the file itself. It actually took me a little while to discover that the error was pointing at a file that was not the culprit. That file was calling another that was the problem.
Anyway, try to check the said file directly.
And could you also check the files concrete/src/Http/Request.php and concrete/src/Http/RequestBase.php
Anyway, try to check the said file directly.
And could you also check the files concrete/src/Http/Request.php and concrete/src/Http/RequestBase.php
I have checked both of these, and they have the correct owner and permissions.
When I run chown and chmod it's run as root, and I have never had issues with forcing the ownership or permissions of a file
I also did a random check on the rest and they are all set correctly
When I run chown and chmod it's run as root, and I have never had issues with forcing the ownership or permissions of a file
I also did a random check on the rest and they are all set correctly
I had some date-time related problems when I allowed concrete5 to install with the default php time, which was GMT taken from php.ini. Using the advanced options on install to select London solved the problem.
(I can see why such a 1 hr time skew would be relevant in the summer, but in the winter London == GMT, so the above could be spurious information)
(I can see why such a 1 hr time skew would be relevant in the summer, but in the winter London == GMT, so the above could be spurious information)
I had drawn that conclusion because when I ran the installer it did complain about the timezones which I had to correct before it would run.
I took the live database and applied it to my dev env which continued to be faulty.
I have since run some more tests and including taking a running installation on a staging env and putting it onto the live server, I have found that while the site worked ok on the staging env, it showed the same faulty behaviour on the live site.
While I need to do some more tests it's starting to suggest its a database issue.
I also found that when installing stucco onto a clean install it did throw a 500 error during the install, but seems to be ok now, I need to wait 24 hours before I can confirm that.
Why 24 hours, that was how long the last one took to break.
I will keep this thread updated.
Martyn
I took the live database and applied it to my dev env which continued to be faulty.
I have since run some more tests and including taking a running installation on a staging env and putting it onto the live server, I have found that while the site worked ok on the staging env, it showed the same faulty behaviour on the live site.
While I need to do some more tests it's starting to suggest its a database issue.
I also found that when installing stucco onto a clean install it did throw a 500 error during the install, but seems to be ok now, I need to wait 24 hours before I can confirm that.
Why 24 hours, that was how long the last one took to break.
I will keep this thread updated.
Martyn
This issue hasn't gone away but I have made some progress.
In frustration, I created another instance of the website on the cloudnx server mapped to a different url. I did this by uploading the code from my development. Then restored a backup from the same development.
All went well and for 1 hour all worked as expected. I could edit content, access the dashboard,. Logout, login. All of the usual stuff you want to do.
! hour later and I an getting the same strange behavour. All the things I could do before I can't, albeit the website is alive and browseable.
When I try to edit any content such as an html block, an image slider, or just an image block I get a 500, when I try to edit content in a built in content block I can open the content but when I try to save I get this
protected $page; /** @var Permissions This page's permissions */ protected $permissions; public function on_start() { $request = $this->request; $cID = $request->query->get('cID'); if (!$cID) { $cID = $request->request->get('cID'); } if ($cID) { $page = ConcretePage::getByID($cID); } if (is_object($page) && !$page->isError()) { $this->setPageObject($page); $request->setCurrentPage($this->page); } else { throw new \Exception(t('Access Denied')); } } public function setPageObject(ConcretePage $c) { $this->page = $c; $this->permissions = new Permissions($this->page); $this->set('c', $this->page); $this->set('cp', $this->permissions); } public function action() { if ($this->page->getCollectionPointerOriginalID()) { $cID = $this->page->getCollectionPointerOriginalID(); } else { $cID = $this->page->getCollectionID(); } $url = call_user_func_array('parent::action', func_get_args()); $url .= '&cID=' . $cID;
And a 500 error in the logs.
I have checked with the provider of the CloudNX server, Fasthosts, they are not aware of any issues and say there isn't a proxy or caching server in the path, there is a firewall locked down to specific ports, TCP: 22, 80, 443, 8443, 8447.
I did have a lot of issues installing the OS which was provided by Fasthosts, it came preloaded with a lot of extras I had to uninstall. I intend to rebuild the server 1 last time with a vanilla copy of Ubuntu, (awaiting the instructions on how to provide my own image.)
Any ideas on this most welcome, because I am running out of them fast.
In frustration, I created another instance of the website on the cloudnx server mapped to a different url. I did this by uploading the code from my development. Then restored a backup from the same development.
All went well and for 1 hour all worked as expected. I could edit content, access the dashboard,. Logout, login. All of the usual stuff you want to do.
! hour later and I an getting the same strange behavour. All the things I could do before I can't, albeit the website is alive and browseable.
When I try to edit any content such as an html block, an image slider, or just an image block I get a 500, when I try to edit content in a built in content block I can open the content but when I try to save I get this
protected $page; /** @var Permissions This page's permissions */ protected $permissions; public function on_start() { $request = $this->request; $cID = $request->query->get('cID'); if (!$cID) { $cID = $request->request->get('cID'); } if ($cID) { $page = ConcretePage::getByID($cID); } if (is_object($page) && !$page->isError()) { $this->setPageObject($page); $request->setCurrentPage($this->page); } else { throw new \Exception(t('Access Denied')); } } public function setPageObject(ConcretePage $c) { $this->page = $c; $this->permissions = new Permissions($this->page); $this->set('c', $this->page); $this->set('cp', $this->permissions); } public function action() { if ($this->page->getCollectionPointerOriginalID()) { $cID = $this->page->getCollectionPointerOriginalID(); } else { $cID = $this->page->getCollectionID(); } $url = call_user_func_array('parent::action', func_get_args()); $url .= '&cID=' . $cID;
And a 500 error in the logs.
I have checked with the provider of the CloudNX server, Fasthosts, they are not aware of any issues and say there isn't a proxy or caching server in the path, there is a firewall locked down to specific ports, TCP: 22, 80, 443, 8443, 8447.
I did have a lot of issues installing the OS which was provided by Fasthosts, it came preloaded with a lot of extras I had to uninstall. I intend to rebuild the server 1 last time with a vanilla copy of Ubuntu, (awaiting the instructions on how to provide my own image.)
Any ideas on this most welcome, because I am running out of them fast.
concerning your timezone theory, did you check and compare server timezone and the one you set in C5?
Did you also check your permissions? Wouldn't you by any chance have any of those timed group removal in place?
I'm sorry this is fairly obvious stuff I'm asking but like you, I can't think of anything else.
Did you also check your permissions? Wouldn't you by any chance have any of those timed group removal in place?
I'm sorry this is fairly obvious stuff I'm asking but like you, I can't think of anything else.
hi mnakalay,
Don't be sorry any question about this is welcome,
I have double and triple checked the timezones and tried most combinations. When you run the C5 install it complains if the timezones don't match, To run the install I had to have matching TZ.
Permissions all checked and all say Administrator ( I am logged in as the only Admin)
No group removals and in fact no user groups defined.
I am currently testing a theory related to the Theme and a conflict. I have a clean copy of the website built and I want to see if after an hour it shows the same behaviour only (20 mins to go on this one).
If it passes that test then I will install the theme and leave it another hour and so on.
Ultimately I may end up rebuilding the site in stages, it's only 5 pages, by hand to try to identify the cause. If the theme passes then I will add the few blocks and so on.
I also have another more drastic option and that is to trash the OS and rebuild it with a vanilla ISO, which I have managed to get guidance on from Fasthosts.
Don't be sorry any question about this is welcome,
I have double and triple checked the timezones and tried most combinations. When you run the C5 install it complains if the timezones don't match, To run the install I had to have matching TZ.
Permissions all checked and all say Administrator ( I am logged in as the only Admin)
No group removals and in fact no user groups defined.
I am currently testing a theory related to the Theme and a conflict. I have a clean copy of the website built and I want to see if after an hour it shows the same behaviour only (20 mins to go on this one).
If it passes that test then I will install the theme and leave it another hour and so on.
Ultimately I may end up rebuilding the site in stages, it's only 5 pages, by hand to try to identify the cause. If the theme passes then I will add the few blocks and so on.
I also have another more drastic option and that is to trash the OS and rebuild it with a vanilla ISO, which I have managed to get guidance on from Fasthosts.
I just checked again and actually my first request that you check file's chmod situation was wrong. I misread your message and looked at the wrong file.
I am now looking at the right file and I'm wondering if maybe you could check your htaccess.
I remember seeing something a bit like this on a site that had pretty URLs enabled but the bit in htaccess supposed to deal with that was wrong. I think it was from a legacy version of C5 and was throwing havoc.
Can you check if your pretty URL situation is consistent with what's in your htaccess and that your htaccess code is really the one recommended by C5?
I am now looking at the right file and I'm wondering if maybe you could check your htaccess.
I remember seeing something a bit like this on a site that had pretty URLs enabled but the bit in htaccess supposed to deal with that was wrong. I think it was from a legacy version of C5 and was throwing havoc.
Can you check if your pretty URL situation is consistent with what's in your htaccess and that your htaccess code is really the one recommended by C5?
Also, the error you see comes from this function
SO to get the error, one of the follwing needs to happen:
1- we're not getting a $cID from the request
2- we have a $cID but the page we're getting doesn't exist or has errors
Getting a page by ID first checks the cache and looks for the most recent version. It might then be a good idea to empty the cache.
And from what I can see, if the page is not found in the cache, it grabs it from the DB.
When grabbing the page by ID, the only possible error it is returning is COLLECTION_NOT_FOUND meaning there is a problem with the page or its version.
Another thing is after all that happens, it caches the resulting page again so maybe check your cache folders authorizations?
If I think of anything else I'll let you know but you might want to log yourself through this one to find out at which point it fails.
public function on_start() { $request = $this->request; $cID = $request->query->get('cID'); if (!$cID) { $cID = $request->request->get('cID'); } if ($cID) { $page = ConcretePage::getByID($cID); } if (is_object($page) && !$page->isError()) { $this->setPageObject($page); $request->setCurrentPage($this->page); } else { throw new \Exception(t('Access Denied'));
Viewing 15 lines of 17 lines. View entire code block.
SO to get the error, one of the follwing needs to happen:
1- we're not getting a $cID from the request
2- we have a $cID but the page we're getting doesn't exist or has errors
Getting a page by ID first checks the cache and looks for the most recent version. It might then be a good idea to empty the cache.
And from what I can see, if the page is not found in the cache, it grabs it from the DB.
When grabbing the page by ID, the only possible error it is returning is COLLECTION_NOT_FOUND meaning there is a problem with the page or its version.
Another thing is after all that happens, it caches the resulting page again so maybe check your cache folders authorizations?
If I think of anything else I'll let you know but you might want to log yourself through this one to find out at which point it fails.
I did turn on pretty urls...
When I switch it off it starts working again... Now I reserve judgement for hmm 1 hour because it did this before but I a mildly confident about this.
I will provide, hopefully the final update sooooon.
Thanks for sticking with this one..
Martyn
When I switch it off it starts working again... Now I reserve judgement for hmm 1 hour because it did this before but I a mildly confident about this.
I will provide, hopefully the final update sooooon.
Thanks for sticking with this one..
Martyn
I am pleased to say that I am in control again, this was indeed the issue
Thanks goes to Mnakalay
Thanks goes to Mnakalay
Glad to hear it. This was starting to drive me insane :)
hi,
it's not apache/htaccess its nginx but this had me thinking about versions of nginx. I was just starting to look at this when your second message arrived
it's not apache/htaccess its nginx but this had me thinking about versions of nginx. I was just starting to look at this when your second message arrived
Thank you so much for this!
I recently installed clean copy of c5-8.4.4
Today I had some blank white error dialogs pop up when saving a new page based on a new, recently created, page-type. When I checked the Log table I had five of the following exceptions in the table.
Exception Occurred: /home/tcbmlive/public_html/concrete/controllers/backend/user_interface/page.php:31 Access Denied (0)
All my folders have there permissions set to 775 and all my files are set to 664.
I changed the permissions on just page.php to 775 from 664 and the problem stopped occurring.
What's up with this?
Today I had some blank white error dialogs pop up when saving a new page based on a new, recently created, page-type. When I checked the Log table I had five of the following exceptions in the table.
Exception Occurred: /home/tcbmlive/public_html/concrete/controllers/backend/user_interface/page.php:31 Access Denied (0)
All my folders have there permissions set to 775 and all my files are set to 664.
I changed the permissions on just page.php to 775 from 664 and the problem stopped occurring.
What's up with this?
