esspeedee

Hi Nikhil,

Sorry its taken a few day to respond. I’ve been away…

I have inserted your code and it works perfectly.

I just want to say a big thanks for being so responsive and helping me with this.

Hi,
Thanks for the update.

The hosting company and I spent a log time trying to get this to operate. They could not identify (in the event log) the specific modsec rule being triggered.
What we (as best as we could) confirmed is that ModSec is blocking the reload of login.php.

In the end, I have to replace the plugin with a similar plugin from bestwebsoft. That plugin works really well. In essence it doesn’t (seem) to reload login.php. So modsec cannot block any reload.

But thanks for the plugin. It has been terrific, but sadly we could not continue with modsec disabled.

Regards and thanks again,

This update might help:
After trying for some days to fix this, it seems like ModSecurity could be involved.

If I disable ModSec the Two Factor plugin works.

However, with ModSec enabled, the first loading of wp-login.php (with the userid and password) loads OK, but the second loading of wp-login.php which is asking for the 2FA code fails to load fully. It seems to load about 50% of the page then just stops.
The submit section and the javascript part of the 2FA form do not load.

This has only just started happening. I wonder if there has been a recent update to ModSec?

I cannot say for sure if ModSec is blocking it. But with the limited access I have to the host server, it looks like it could be contributing.

I hope this helps. I would greatly appreciate any feedback or help with this issue, please?

Thanks

Hello @yeisonbp,
Thanks for that link. I had already seen that one, but it sadly does not help too much.

The BIG issue for this plugin (in relation to GDPR and cookie compliance) is that it drops a cookie immediately, and without consent. Being able to delete a set cookie is not the same as not setting it.
I think cookie compliance is going to be the next big headache for EU websites.

The wpas documentation provides a number of API calls that (would appear to) prevent the session being established. However that cookie still places. So either the API is unclear or faulty of the cookie will be set even though no session is established. Why, I don’t know. I was hoping for some answers from wpas but nothing is forthcoming. Not very awesome ??

My long-term solution, therefore, is to drop this plugin and find something else that works better.

In case anyone is interested, I have coded sort of a fix, using a cookie bar acceptance plugin. What happens is this:
1) The visitor lands on a welcome page, and wpas drops its session cookie.
2) If there IS a compliance cookie set, then I expose the wpas “[tickets]” as usual.
3) If there is NOT a compliance cookie, I delete the wpas session cookie, and hide the wpas “[tickets]”.

The result is that the visitor has to accept cookie compliance before they get to the wpas tickets, and no cookie is evident.

The only “gotcha” is that the wpas cookie is set, but immediately removed. This means that the solution is not entirely GDPR compliant because the cookie is actually set albeit only for a fraction of a second.
But the solution works, for the moment.

I hope this approach might help others.

Thanks again for the response and link. Much appreciated.