Google 403 and 404 errors

Google redirects to the same page with 403 or 404 error when trying to connect:

These 403 and 404 errors are related to:

  • a server setting, or maybe a firewall that does not allow passing http/https links in the URL
  • an exceeded Google App limit.

Use case:

When the user tries to log in with the Google Porivder, the URL in the Pop-up will be similar like:
The problem is related to these two old scopes:


To avoid this problem, we are already using the new scopes since Nextend Social Login 3.0.14:

  • email
  • profile

which are the new equivalents of the old scopes. However Google still returns the old scopes in the returned URL.

That the issue is actually related to these old scopes can be confirmed by replacing the old scopes in the URL with the new ones like:

Once it is done, the authentication will be successful, which means your server or firewall block the URLs which have http/https links in them.

Fix for self hosted sites:

  • Go to your WHM (web hosting manager), and search for ModSec, select “ModSecurity Configuration” from the results and check that you are logging transactions at the “Audit Log Level”. You can switch this back to not logging when you’re done here, but need this to be logging activity when testing the google verification process.
  • Go to your Nextend Social Login settings, and try verifying Google again.
  • Now within WHM select ModSecurity Tools from the options there.
  • On the ModSecurity “Hit List” you’ll see a list of events with dates and times. Inspect the timeframe that corresponds to the verification test that failed.
  • Scan over to the “Rule ID” and write down the Rule ID numbers that correspond to each item/event that resulted in a 404 status.
  • Now go to the ConfigServer ModSec Control plugin of WHM (listed in results of the Modsec search). Select the database user that corresponds to the website/url you want the google social login to work on, and click “Modify user whitelist”.
  • On the resulting screen, select the domain and click “Modify domain whitelist”. Then on the resulting screen enter the ModSecurity rule IDs you wrote down. Click “save white list” for the domain. Now return to the Nextend Social Login settings, and try verifying google again.
  • If it works you know at least one of those rule IDs was responsible. Now go back and figure out which one it is – for instance, if you identified 3 rule IDs, try removing one at a time from your whitelist, and see if google will still verify. You might find that of the three rules, the presence of just one in the white list will enable google to verify. You want to whitelist as few rule IDs as you can, to insure greater security for your website. You may find yourself having to pick between two rules, where each one when whitelisted will allow google to verify. In this case, it’s a question of which one is the best one to use (e.g., which one has the least critical severity rating). Some third parties provide a ModSecurity core rule set inventory that can help with this decision, allowing you to make comparisons between rule IDs to determine which is least critical to your website security.

The steps above are provided by Stefan Christian Densmore. Thank you for sharing your experiences with the Nextend Social Login community!

Other suggestions:

Unfortunately there is nothing on our end, that could be done to avoid this issue, since the returned scopes are depend on Google.

  • If you have an official host, then we would suggest getting in touch with them, asking to enable these HTTP/HTTPS links in the URL. Maybe the fix mentioned above, will also help them in solving the problem.
  • To avoid the limitations of unverified Apps, please submit your Google App for a review!