Cacti: Unable to login due to incorrect default of Cookie Domains in config.php.dist

[gbonny1982]

Yesterday I was able to login on 1.2.11, I cannot anymore now.

I've upgraded yesterday cacti & spine from 1.2.7 to 1.2.11. I was not able to install cacti with templates, stuck on 42% twice, so deselected them. Pre-requisite checks were all fine.

I did restart apache2, did a reboot, tried different browser, in privacy mode too. I'm glad I have snapshots.. Nothing related in cacti.log or cacti_stderr.log.

[anarkia1976]

I can confirm the problem when we upgraded release from 1.2.10 to 1.2.11, we can fix the problem with a restore of the previous release. thanks a lot.

[batman978]

same here. upgrade from 1.2.10 to 1.2.11 stuck on the templates; install didn't complete.
attached the end of my install-complete.log:

install-complete.log

how to I restore back to a previous release? I have the database and website backed up. thank you

[bmfmancini]

@batman978 to restore copy the website files back then restore the db
mysql -u root -p cacti < cacti_back_file.sql

I have not been able to reproduce this yet

[bmfmancini]

Yes I can reproduce this
Upgrade from 1.2.10 to 1.2.11 I was able to login after the install but unable to after I logged out
checking more

[bmfmancini]

Seeing the following in the browser console when trying to login

Unchecked runtime.lastError: The message port closed before a response was received.

[KnoAll]

I have also seen trouble logging in after upgrade. On one of my tests login to v1.2.3, upgrade to 1.2.11, can no longer log in. Trying to find a way to reproduce consistently

[bmfmancini]

I upgraded from 1.2.9 to 1.2.11 just fine but I tried this in the lab and it does fail
seems to be a DB level issue though I think the upgrade process kills the auth

The code its self should be fine as a fresh install works just fine
I have not seen any PHP errors or anything like that
also I noticed even if you enter bogus creds cacti doesn't come back with an invalid user message almost like the login didnt procces at all

[bmfmancini]

Ok I re-did the upgrade but stayed logged in so I could enable devel logging
here is the call when a user is created

2020/04/08 12:16:08 - DBCALL DEVEL: SQL Save on table 'user_auth': 'a:18:{s:2:"id";s:1:"0";s:8:"username";s:5:"test2";s:9:"full_name";s:0:"";s:8:"password";s:60:"$2y$10$/78T/rNdHLacsQJgjEa6GOXl8eLeaFe8k8UtZR.8ZN6vryLejqv6q";s:20:"must_change_password";s:0:"";s:15:"password_change";s:2:"on";s:9:"show_tree";s:2:"on";s:9:"show_list";s:2:"on";s:12:"show_preview";s:2:"on";s:14:"graph_settings";s:2:"on";s:10:"login_opts";s:1:"1";s:5:"realm";s:1:"0";s:16:"password_history";b:0;s:7:"enabled";s:2:"on";s:13:"email_address";s:0:"";s:6:"locked";s:0:"";s:11:"reset_perms";i:416694879;s:15:"failed_attempts";i:0;}'

[KnoAll]

Trying to manually reset the pw in mysql does not seem to help either.

[gbonny1982]

fwiw, I've followed this upgrade guide:
https://www.cacti.net/downloads/docs/html/upgrade.html

I have cacti downloaded & extracted to /opt/cacti

Updated user/password/database:

sudo vim cacti/include/config.php

Copied scripts / rra / resource from previous install.

additionally:

cd cacti
sudo chown -R www-data.www-data /opt/cacti/
sudo chown -R cactiuser.www-data rra/
sudo touch log/cacti.log
sudo chmod 664 log/cacti.log
sudo touch log/cacti_stderr.log
sudo chmod 664 log/cacti_stderr.log
sudo chown -R cactiuser:www-data log/
sudo chown -R cactiuser.www-data cache/

and then followed install/upgrade instructions in webbrowser.

download & extract spine in /opt/cacti-spine/

additionally:

cd cacti-spine
sudo ./bootstrap
sudo ./configure
sudo make
sudo make install

sudo vim /opt/cacti-spine/spine.conf.dist
sudo vim /usr/local/spine/etc/spine.conf.dist

update database/user/passwd

to resolve: DEBUG Falling back to UDP Ping Due to SetUID Issues

cd /usr/local/spine/bin/
sudo chmod u+s spine

[bmfmancini]

Tried on ie,chrome,firefox all doing the same thing
cookie based Auth works fine

[bmfmancini]

Wait a minute...are you guys using centos/rhel ?
I just tested with Ubuntu and its working fine....

[KnoAll]

Yes

[bmfmancini]

hmmm I wonder if there is some PHP weirdness going on in centos...on Ubuntu 19.04 everything works just fine I spun up a droplet to test and found out that way

[gbonny1982]

Im on ubuntu 18.04, patched all the way.

[bmfmancini]

Well this is weird ....I cant re-produce it now lol I just created another droplet
installed 1.2.10 then upgrade to 1.2.11 everything is fine ... on centos 7

[KnoAll]

I've seen that inconsistency as well. Sometimes it works, but most of the time not. I've tried this on a couple of versions of CentOS. 7.1 and 7.5 with with matching different PHP versions. I'm working on setting up a CentOS 8.1 to test with...

[KnoAll]

Just reproduced on CentOS 8.1 PHP v7.2.11. Cookie auth works, but not when you go private and are forced to login.

[gbonny1982]

index.php & install.php & host.php & tree.php & clog.php doesn't give an error when trying to log in. graph_view.php gives an error like incorrect username or password.

Why does this differ?

[TheWitness]

Okay, this is interesting. Are any of you guys copying the config.php.dist to config.php? If so, comment out the $cacti_cookie_domain line. This was supposed to be commented out, but for some reason (likely late night), it was not commented out.

I experienced the same thing after getting the release version from cacti.net on my test system. I was event logged out of my active session. However, as soon as I commented it out of the default install, everything went back to normal.

So, if this is in fact the case, the Cookie domains are proving to be working. Apologies.

[bmfmancini]

Ah ok that explains it ! looks good so far
@TheWitness since this is a pretty big one could 1.2.11 be re-packaged under the zip releases so someone downloading the zip wont get stuck being unable to login after install ?

Or maybe a note saying its a known issue ?
Maybe we could also do that for 1.2.10 since that had a install bug as well

[TheWitness]

I know. I'm regretting moving so quickly on this. Well, 1.2.10 did not have the cookie domains in it. So, it's separate. @ronytomen who has trained @netniV pretty well, has disdain for repackaging.

[KnoAll]

Your indicated workaround seems to help with the authentication issue.

[ank0l0g]

Commenting the line $cacti_cookie_domain helped. Login succeeded. Cacti 1.2.11

[gbonny1982]

I can confirm commenting out "$cacti_cookie_domain" in "cacti/include/config.php" helped.

[sd3m0n]

I can also confirm commenting out "$cacti_cookie_domain" in "cacti/include/config.php" helped.

When upgrading from 1.2.10 to 1.2.11 installer was not able to install cacti with templates and stucked at 42%. For that I used the solution from https://github.com/Cacti/cacti/issues/3401#issuecomment-609022683 and it worked.

[ixinshang]

thanks. it's works.

[majed17]

thanks, i was getting worrisome with both servers in non working position

[netniV]

This is an unfortunately error in the distribution configuration file. Since it should only affect new installs, I think it will be safer to wait for the normal packaging cycle especially given there is a documented fix.

The disdain for repackaging also comes with the same disdain for quick fire releases or too soon after a major commit. This is why we have sometimes delayed the packages a bit longer. However, this seems to have slipped through all nets somehow (likely because we were logged in and didn't copy over the config!).

[KnoAll]

Not sure what you mean by only new installs? I am seeing this on upgrades as well. The upgrade instructions direct to use the config.php from the new package and update the credentials. (which includes the uncommented "$cacti_cookie_domain"

[bmfmancini]

Hey Guys

We could also add a new zip file to the github release repo as well
or under the release notes in github for 1.2.11 since its the latest release I am sure most people would download the latest release marked stable

Thanks !

[TheWitness]

I have to say I sprained my leg having kicked myself in the ass repeatedly over this.

[bmfmancini]

No worries @TheWitness happens to the best of us
I just dont want someone to download the zip and have this issue and not know its a known issue

[netniV]

Not sure what you mean by only new installs? I am seeing this on upgrades as well. The upgrade instructions direct to use the config.php from the new package and update the credentials. (which includes the uncommented "$cacti_cookie_domain"

OK to me that is more a new install if you are replacing configuration files. Most upgrades, via git or system packages will not replace the configuration file. Personally, I prefer to use the git method and switch to the current release tag as I find it cleaner.

Some people still prefer the old ways though, like @TheWitness, who prefers to copy and replace stuff, but even with his methods, you shouldn't need to replace the config.php unless absolutely needed. Copying the config.php.dist file should only occur on a new install or if there is a new configuration variable you want to take advantage of. At least that's my view on it.

[netniV]

In fact, if you have any kind of custom security in place, which all my cacti instances have their own usernames, passwords, databases and folders, then you have to update a load of stuff if you replace the config.php

[gbonny1982]

In fact, if you have any kind of custom security in place, which all my cacti instances have their own usernames, passwords, databases and folders, then you have to update a load of stuff if you replace the config.php

Its not about what KnoAll prefers, netniV, its about what the upgrade instructions tell us here:
https://www.cacti.net/downloads/docs/html/upgrade.html
Maybe someone can update them. Add another upgrade path, where one is preferred above the other. People read those instructions, as you can see there are many #metoo here.

[netniV]

Yeah I can 👍 I was thinking the same thing. I don't think our main site has been revised in a long time. The documentation repo does have a few different installation guides. But it is about what you prefer (or know) since I know several methods of doing the upgrades, I ditched the system packages in favour of source upgrading (as per the above guide) and then eventually I ditched that in favour of git 👍

Really, the part about editing config.php should suggest copying that away for safety and then back again after the other copies, what do you think @TheWitness ? You should only ever need to edit config.php on a new install.

[TheWitness]

Here is my refresh script. I don't even have a config.php ;) High home security, I know.

refresh.sh

#!/bin/sh
rm -rf cacti-develop
git clone -b 1.2.x https://github.com/Cacti/cacti.git cacti-develop
/bin/cp -rpf cacti-develop/* cacti
chown -R apache:apache cacti

Just change apache with nginx if you are using nginx. I think that this should be the upgrade procedure, or something close to it. It does not wipe out any of your plugins, it 'will' wipe out any modifications to standard package resource and scripts, which of a concern, and why we need to work on those and their version control. But hey it works.

[TheWitness]

The version control is long overdue, and maybe a 1.3 project.

[rcsmota]

Comment out the $cacti_cookie_domain line work well here.

New installation of Cacti 1.2.10.

[DY-1990]

Comment out the $cacti_cookie_domain line NOT work for me. why there is a such big BUG with this new version...

[DY-1990]

I downgrading to 1.2.5 in the end. I suggest skip this version if you running Centos7 as operating system. too much troubles for me. spend almost a half week to fix it.

[netniV]

Comment out the $cacti_cookie_domain line NOT work for me. why there is a such big BUG with this new version...

The it is likely it was not just due to this bug. If you have already downgraded then it won’t be something that we can diagnose until you next upgrade but I would suggest opening your own issue for clarity.

[mpaulino710]

Hello, any different solution? I have tried several options without success

[TheWitness]

Please update the include/global.php from the 1.2.x branch and let us know what happens.

[ADeeeee]

Hi all,
Just updated from 1.1.38 to 1.2.12 by following official document sucessfully two days ago and then boom!

Uncommenting the $cacti_cookie_domain doesn't work for me. Any fixes or workaround I can do for it?

UPDATE:
"update the include/global.php from the 1.2.x branch" fixed it

UPDATE2:
I make a diff between the 1.2.x branch and mine and I see the only difference is "SameSite legacy behavior" header. Maybe it's the root cause?

UPDATE3:
I'm sorry. Just found that only admin works, not for other accounts