Home› Plugins

Menu_manager

L68stingray Member
in Plugins

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.

Tags:

Comments

  • acrylian Administrator, Developer

    This is sadly an already known bug.

  • stalker Member

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

  • acrylian Administrator, Developer

    Fix is in 1.6.1a aka master on Github already.

  • L68stingray Member

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

  • acrylian Administrator, Developer

    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 Member

    Thank you for the fix.

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

  • bpreston Member

    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 Administrator, Developer
    edited September 2023

    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 Member

    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 Administrator, Developer
    edited September 2023

    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 Member
    edited September 2023

    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 Administrator, Developer

    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 Member

    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 Administrator, Developer

    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…?

Sign In or Register to comment.