[CSRF woes continue]

The IPN logs are present and look fine. Status completed with response code 200

[CSRF woes continue]

Thank you @Dirty Butter

[CSRF woes continue]

ideas?

[CSRF woes continue]

I managed to log the PayPal  IPN POST  data and I can see in it ...

payment_status=Completed

Order status never gets updated.

[CSRF woes continue]

Side question:  An order is created the moment the user jumps over to paypal, whether they pay or not. I don't care for this but.. the question I have is with IPN.. i can see the IPN POST in the web server log with status code 200.  The order status never leaves 'Pending'.  Is this by design or perhaps IPN is failing on me silently.

Leads me to believe that IPN post should set it to 'processing'.  Is that correct?

[CSRF woes continue]

When finishing payment and returning from Paypal, to the return URL

/index.php?_a=complete

It shows the csrf error.

I am running under SSL and all http requests get redirected by the web server to https. I manually replaced the `return` URL to the explicit form.

in /modules/gateway/PayPal/gateway.class.php

    //'return'       => $GLOBALS['storeURL'].'/index.php?_a=complete',
    return'        => 'https://mydomain.com/index.php?_a=complete',

Reason being I don't know where to var_dump the GLOBALS and there is some weirdness in the admin form under store>settings>ssl where you can select 'enable ssl'.  That checkbox works, but the store url refuses to save as https. Basically did this in order to avoid a problem with redirection from the web server as the root of the csrf problem.

It seems like perhaps the problem is in

classes/sanitize.class.php

Where there is an explicit exception made for payment gateways. Because the very first condition is  !isset($_GET['_a'])   I can assume that the return URL is going to fail this every time whereas IPN will work with this condition.

 

if (!empty($_POST)) {
        $csrf_exception = false;
        // Exception for payment gateways
        if(!isset($_GET['_a']) && isset($_GET['_g'], $_GET['type'], $_GET['cmd'], $_GET['module']) && in_array($_GET['_g'], array('remote','rm')) && $_GET['type']=='gateway' && in_array($_GET['cmd'], array('call', 'process')) && !empty($_GET['module'])) {
                $csrf_exception = true;
        }

        // HACK to deal with CSRF POST token problems with PayPal return  -----------------------------------
        if ( isset($_GET['_a']) && $_SERVER['REQUEST_URI'] == '/index.php?_a=complete' ) {
            $csrf_exception = true;
        }

        //Validate the POST token
        if (!$csrf_exception && (!isset($_POST['token']) || !$GLOBALS['session']->checkToken($_POST['token']))) {
                //Make a new token just to insure that it doesn't get used again
                $GLOBALS['session']->getToken(true);
                self::_stopToken();
        }
        //Make a new token
        $GLOBALS['session']->getToken(true);
}

So yeah. This works but without having more knowledge about the inner workings of this code I suspect there are better ways to handle this. Worse, this is obviously not very hardened.

Please lend me some insight here.

thanks

[[Resolved] 6.1.7 to 6.1.8 can't login to admin]

Ok. I found the issue.  I've been using NGINX and the problem is that $_SERVER['PHP_SELF']  is not available in the fastcgi / php / nginx  set up by default. I had read that it was a security issue to enable `cgi.fix_pathinfo = 1`   here

https://www.digitalocean.com/community/tutorials/how-to-install-linux-nginx-mysql-php-lemp-stack-in-ubuntu-16-04

but then contradicting statements here

https://stackoverflow.com/questions/23390531/access-denied-403-for-php-files-with-nginx-php-fpm

https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/

 

The solution was to change cgi.fix_pathinfo from 0 back to 1 and then add lines to the nginx conf for the virtualhost.

http://kbeezie.com/php-self-path-nginx/

and

https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/

 

[[Resolved] 6.1.7 to 6.1.8 can't login to admin]

I think I'm getting closer.  The admin login form has a hidden tag for redirect that is pointing to the root url rather than the admin path.  On the working installation the hidden tag looks like

 

<input type="hidden" name="redir" value="https://testing.snizzlebizzle.com/admin_xxx.php?_g=login">

and the upgraded version is...

<input type="hidden" name="redir" value="https://testing.snizzlebizzle.com?_g=login">

I presume it's redirecting as a result.

 

12 hours ago, Dirty Butter said:

Welcome to the forums@mrfackler.

Please check to be sure the admin_xxx.php and the admin_xxx folder both match what is in global.inc.php. I know I can't save changes to the global includes file unless I change permission, make the change, and then reset the permission.

Dirty Butter:  Yes, the files are uniformly named and permissions are correct.

[[Resolved] 6.1.7 to 6.1.8 can't login to admin]

I've gone through the forums looking for a solution but no luck, so here goes a post.

Running 6.1.7 and only using Paypal for payments customers complaining that orders don't go through and they are seeing the CRSF message. Have seen other reports of this but the solutions didn't help me. Appeared fixed in 6.1.8 so here is the upgrade steps I took.

• I started a manual upgrade and a full backup of data and files.
• Deleted files in cache/skins
• Overwrote directory files with zip file contents
• Browse to /setup and start upgrade process which completes without issue
• Change directory name of admin_ to match admin_xxx.php script
• Update includes/global.inc.php  to reflect the random admin script/dir naming

From here, attempting to log in to the admin immediately redirects to the store home page with the Invalid user/pass error message.

As mentioned throughout the forum, I enabled the error logging mechanism but it didn't really yield anything of interest.  I've had to temporarily roll back to the old version.

Any help appreciated.

thanks!