Menu_manager

L68stingray

I am new to ZenPhoto. I'm trying to make a new menu item to link to my car clubs home page. I am using the theme collections.
When I add a new menu item (custom link) when I hit apply I get the following error.

“update_menu” Cross Site Request Forgery blocked.

acrylian

This is sadly an already known bug.

stalker

It's really sad because I have same problem. Maybe some workaround exists? Manual change in the code?

acrylian

Fix is in 1.6.1a aka master on Github already.

L68stingray

When will I be able to upgrade? How do I access the SW. I installed it from Blue Host Softaculous

acrylian

It is obviously not an official release yet and we are still working on several things.

If you like to try early the link to that is on our download page. Install instructions are the usual ones on https://www.zenphoto.org/news/installation-and-upgrading/

It might work to just copy the plugin in this case.

I installed it from Blue Host Softaculous

We are not involed with such install helpers and they are their vendors domain. If you like to use them you will have to wait for the official release.

ctdlg

Thank you for the fix.

It does work, I just copied the plugin ( menu_manager folder and menu_manager.php file) as suggested.

bpreston

The XSRFdefender function is causing us much grief. It is triggering often for users and it's difficult to determine exactly what is causing it to fail.

Upgraded to 1.61a and it has not helped.

Debugging shows that the SystemToken and RequestToken don't match--the latter often comes back as blank, causing albumedit (and others) to fail.

Is there a way to completely disable the XSRF checks in the newer versions of the software, or provide you steps for reproducing or debug information?

Thanks.

acrylian

The XSRFdefender of course cannot be disabled.

Be sure that the users have cookies enable or try to use sessions (see options). Also check any ad blocker or similar browser addons to be configured properly.

We don't see or can reproduce any general issue besides the menu manager specific one we noted above.

bpreston

Cookies are enabled. Tried with fresh copies of Chrome, Firefox and Edge on multiple machines.

php_sessions option did not make a difference.

I'm able to trigger the error "albumedit Cross Site Request Forgery blocked " consistently by editing an album and entering 100 lines of text in the description field for an image, then hitting apply.

It does not occur when I directly attempt the same operation on the same subnet as the server. To my knowledge there is just normal routing to that network (no firewalls/proxies/etc) so I'm unsure what could be going on--which is why I was asking if XSRFDefender could be disabled instead of resorting to running a packet sniffer to find out what is occurring.

acrylian

It does not occur when I directly attempt the same operation on the same subnet as the server.

This topic is about the menu manger bug actually which we could reproduce and fixed in 1.6.1a. I have not seen this issue occur otherwise.

Sessions actually should not be necessary and cookies are far more convenient.

You can look at zp-core/functions.php and the getXSRFtoken() function to see how it is generated:

sha1($action . $_zp_db->prefix(ZENPHOTO_VERSION) . serialize($admindata) . session_id())

So some of these values do not match when you are trying to do things. I would guess it might be the session_id() - a standard php thing independent of our option - for reason I have no idea about.

Try to change that function's last line to something like this:

 $token_values = $action . $_zp_db->prefix(ZENPHOTO_VERSION) .    serialize($admindata) . session_id()
 debuglog($token_values);
 $token = sha1($token_values);
 debuglog($token);
 return $token;

Perhaps you find out what is not matching.

bpreston

After making those mods it burps out a log of debug info on an unsuccessful edit. Looks like this:

TOKEN VALUES FIELDS:
clear_log`_1.6.1a`a:27:{userdata-editied by admin for privacy}j9l947rm30mcgac7tm6fjjr6lj
{10020:Wed, 27 Sep 2023 16:27:13 GMT}
SHA 1 TOKEN :
45fe981689c211fc43cc012c1c335387e79cc98c

The last part of that very long string is the cookie value of the client. It repeats the long lines for numerous functions (clear_cache, imagemetadata,refresh,site_upgrade,etc)

On a successful page edit the output is much cleaner and just looks like this:

SHA 1 TOKEN :
fa37d76d5c6efa66665d10208b7532d04180e51e
{4076:Wed, 27 Sep 2023 16:34:40 GMT}
REQUEST['XSRFToken'] :
fa37d76d5c6efa66665d10208b7532d04180e51e
{4076:Wed, 27 Sep 2023 16:34:40 GMT}

acrylian

The long info part is the user account data (I have removed it as that should not be listed here for ever even if all is hashed).

The last part of that very long string is the cookie value of the client.

That j9l947rm30mcgac7tm6fjjr6lj actually should be the session id.

Still no idea what is happening on your install. THe token is generateed then passed via GET primarily and then compared with a freshly generated one. If it is the same user and install it should be the same. The only thing that could happe is that for some reason the session id is missing or changed to quicky so the token does not match. No idea why that would happen only to you…

bpreston

We found that for whatever reason the code was not sending data back from the client; this was causing the token validation to fail (and sending the client back to the default page, since it had lost track of what page the client was on.)

I did not obey the install requirements.
PHP-8.2.8-win32-vs16-x64 was causing this problem.
PHP-8.1.24-nts-Win32-vs16-x64 is working properly.

Thanks for your help.

acrylian

Thanks for the follow up. Actually plain PHP 8.2 at works without issue as we develop 1.6.1a on it already. 1.6 may have some issues with 8.2+ but we didn't notice any of your issues…

Perhaps also Windows makes the difference here for some reasons…?