prevents GravityView data from loading on password protected page

Hi John,

Thank you for trying my plugin.

You can find “Password protected” in “Login form” >> “Target actions” at “Back-end target settings” section. Please try to disable it then this plugin will do nothing on the password protected pages.

I hope this can help to solve your issue.
Thanks for your asking.

Hey, thanks for the quick reply. I was excited to learn of a solution, but I don’t think it’s quite there yet with the suggestion you offered. I unchecked the password protected (https://gyazo.com/f00fee55659b515ff264e8870118142b) and tried it but it’s doing the stuck loading data thing still.

Could there be another area that’s blocking the data from loading via the gravityview plugin?
John

I looked at the logs and noticed it was blocking ajax. I turned off block by country for this backend setting, still didn’t work. Tried also turning off prevent zero day and that did it. It works with both unchecked for admin ajax/post.
https://gyazo.com/c0c6dff9419e6ca0c1ef9d68161e1b53

Not knowing much about zero day and ajax, does this leave my site vulnerable?

John

Hi John,

Of course, I recommend to enable “Prevent zero-day exploit” which is one of the benefit to use this plugin.

And I think it should work even in your case. Please confirm the followings:

1. To view the contents correctly on the password protected pages, I think a visitor needs to login as a member of your site. Am I right?

2. This plugin assume that a logged in user is identified by the function is_user_logged_in(). If it doesn’t (in case you use plugins something special), please go to 5.

3. On the password protected pages, the file wp-content/plugins/ip-geo-block/admin/js/authenticate.min.js would be loaded. This is needed to work with “Prevent zero-day exploit”. But when you use a cache plugin and provide cached pages to the users who are logged in, this plugin would not work correctly. In this case, please go to 5.

4. On the password protected pages, there should not be any JavaScript error. This is also needed.

I think that finding the blockage in the logs means that your case needs No.5.

5. Please specify the action which is used in the ajax request in order to bypass “Prevent zero-day exploit”. In order to do that, please refer to “this document“. This is far better than disabling “Prevent zero-day exploit” that simply accespts all admin ajax/post requests without any validations.

You’ll be worried about this kind of bypass. So please try to apply “Best settings” at the “Plugin settings” section. This feature would protect against attacks like “Arbitrary File Upload” and “SQL Injection“.

For the techinical details about “Prevent zero-day exploit”, you can find the story at “How does WP-ZEP prevent zero-day attack?“. And also you’ll be interested in this analysis.

I think that it’s quite difficult to fit all the cases with one click solution, but this plugin provides some functionalities to fit flexibly for each case. So please feel free to ask about something more.

Good luck!

• This reply was modified 7 years, 9 months ago by tokkonopapa. Reason: add links

Hi,
I got in touch with the Gravity View support team and provided them with a user ID to log in and attempt to apply the config according to your direction. Here’s what they replied back with:

“I confirmed things are configured properly (according to their filter instructions), so I don’t know what to recommend. I’m afraid I can’t assist further. The correct action is “gv_datatables_data”, according to that doc.”

So unfortunately I am still having the issue with IPGB blocking this ajax action. Do you have any further recommendations for me to look into?

Thank you again for your great support.
John

The admin-ajax.php action is gv_datatables_data. I added that (and other possible culprits) to the whitelist. When that didn’t work, I added a var_dump() statement in the filter code to see if it was ever reached, and it wasn’t.

Here’s the code I added to John’s site.

Hi guys, sorry for my late reply. And Zack, thank you for the code snippet!

To identify the action of ajax, please try followings:

1. Confirm if there is the word “action” in “$_POST keys to be recorded with their values in logs” at “Record settings”.
2. Find the blocked request in Logs and look at “action=xxxxxx” where the “xxxxxx” is exactly what we need to pick up.
3. Add “xxxxxx” into the whitelist of Zack’s code.
4. Put 3. into your “functions.php”. Note that please use “drop-in.php” when you select “my-plugins (ip-geo-block-mu.php)” as “Validation timing” at “Validation rule settings”.

Please refer to https://www.ipgeoblock.com/codex/record-settings-and-logs.html and https://www.ipgeoblock.com/codex/validation-timing.html for those meanings.

It looks a little bit complicated but I believe we can solve this issue.

Thanks for your great cooperation!

This is looking better and better!
I did find $_POST in the log and confirmed “action” is in there..

$_POST data:
draw,columns,order,start,length,search,action,view_id,post_id,nonce,getData

However, it was not in the Record settings under $_POST keys… So I added it, along with the rest of what I found in the blocked log record.

Then, I found this record of a block with action in it action=gv_datatables_data

I looked at the functions.php file and believe that action was already there: so I didn’t change that file.

Validation timings is set to “init” action hook, so I left that as is.

But it is still blocking it.
I’m a bit of hack at this so I might have gotten something wrong. Maybe Zack would be kind enough to log in to the site and double check my settings? (please?)

John

@burnstuff – I think #4 is the key:

Note that please use drop-in.php when you select “my-plugins (ip-geo-block-mu.php)” as “Validation timing” at “Validation rule settings”.

@katzwebdesign
Thanks Zack.
I missed that one. Tried just changing the setting, but it still blocks it so perhaps I need to create a few lines to go into this drop-in.php file and put that in a folder in the ip geo block plugin folder? I started to try to do this but honestly, I haven’t much of a clue as to what those lines of code should be for the drop-in file or for sure where it needs to go. The instructions seem clear and good and all, I’m lacking some essential skills.

Is it the same lines you prepared for the functions file? Would I be overstepping to ask you if you could do this? I’m thinking that if we can see it through to work, I should be able to apply the steps to make my other sites work. If this is an out of scope request, I’d be up to paying for some support time, if that would be an option.

Thank you guys, and @burnstuff, sorry for the result.

I think we need to go back to the basics.

At first, you are OK to add Zack’s code into your theme’s functions.php (not in drop-in.php) because you select “init action hook” as “Validation timing”.

And 2nd, I’d like to confirm that you found a blocked request which included “action=gv_datatables_data” in the “Admin area” section of Logs. Was it true?

Then 3rd, what could you find in the “Result” column at the blocked request? Was it “wp-zep”?

And the last, I should know about all the settings of this plugin so that I can check if I overlook something or not. So could you send me your settings by email? You can save them as a file via “Export settings” at “Plugin settings” section. And also you can find my address at https://github.com/tokkonopapa

I’d appreciate your kind patience.

Thanks.

• This reply was modified 7 years, 9 months ago by tokkonopapa.

Hi
I’d might be frustrated if I was on my own with this but with help from @tokkonopapa and @katzwebdesign, I’m confident we’ll fix it. Thank you both.

1. Regarding the question of the functions.php code that Zack provided; he accessed the site and file and has already added the code. Here is what he inserted:

/**
* Add GravityView actions to IP Geoblock whitelist
*/
function gravityview_ip_geoblock_bypass_admins( $queries ) {

$whitelist = array(
‘gv_datatables_data’,
‘gv_note_add’,
‘gv_delete_notes’,
‘rg_delete_file’,
);

return array_merge( $queries, $whitelist );
}

add_filter( ‘ip-geo-block-bypass-admins’, ‘gravityview_ip_geoblock_bypass_admins’ );

I have tested this with this code in place for init only as I’m not understanding what code to insert in the drop-in file. Zack might provide that to me, as I did ask, but unless he, or you, provide it for me, I’m not able to test with drop_in.

2. I have noticed the action=gvtables in the admin log:

US wp-zep POST[80]:/wp-admin/admin-ajax.php
User agent:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
HTTP headers:
HTTP_REFERER=https://www.chnevents.org/order-reports/,HTTP_DNT=1,HTTP_X_REQUESTED_WITH=XMLHttpRequest,HTTP_ORIGIN=https://www.chnevents.org
$_POST data:
draw=1,columns=Array,order=Array,start,length=150,search=Array,action=gv_datatables_data,view_id=5360,post_id=5363,nonce=58e70dfb84,getData=[]

3.Yes, the result is wp-zep

I will try to make the drop-in file myself today to see if I get lucky :-). But if you can provide it (using Zack’s code?), that would be helpful.

I can also share screens with you via teamviewer or skype, if you’d like. I’m 5 hours ahead of you.

J

• This reply was modified 7 years, 9 months ago by burnstuff.

Dear all,

I found that the theme used in @burnstuff site would not call Zack’s code on the password protected page. According to Action Reference, the functions.php should be loaded at after_setup_theme which is always fired before init action hook.

Anyway, the final solution is as follows:

1. Add define('IP_GEO_BLOCK_DEBUG', true); in wp-config.php.
2. Put gv_datatables_data into “Exception for admin action and page” at “Back-end target settings” section of this plugin’s settings page.
3. After saving settings, you can safely remove the definition of 1.

Actually, 2. is almost same as Zack’s code but hidden fallback functionality.

Conclusion: This issue might not be related to GravityForms and GravityView.

I hope this helps to resolve this issue.

Thanks.

• This reply was modified 7 years, 9 months ago by tokkonopapa.
• This reply was modified 7 years, 9 months ago by tokkonopapa.

Very nice to have a solution to this issue, even if the problem isn’t fully understood at this time. I will pass it along to the Elegant Theme folks, who make the Divi theme that I use and that may be at the heart of this problem.

Again, a big thank you for the collaborative efforts to resolve this by @tokkonopapa and @katzwebdesign. Both IP Geo Block and Gravity View are important to my work so I’m grateful to find a way for them to work together, along with the Divi theme.
J