$100 Website Offer

Get your personal website + domain for just $100.

Limited Time Offer!

Home Uncategorized Master Troubleshooting Guide: Flarum Google Login OAuth Issue on cPanel/Apache with WordPress Root Site

Master Troubleshooting Guide: Flarum Google Login OAuth Issue on cPanel/Apache with WordPress Root Site

Uncategorized rajeshkumar · June 20, 2026 · 0 Comment

1. Environment Overview

This guide is based on a real troubleshooting case where:

WordPress is installed at the root domain:
https://www.truereviewnow.com
Flarum is installed under a subdirectory:
https://www.truereviewnow.com/forum
Server path:
/home/ireviewed/public_html
WordPress root path:
/home/ireviewed/public_html
Flarum path:
/home/ireviewed/public_html/forum
Flarum config URL:'url' => 'https://www.truereviewnow.com/forum',
Google OAuth callback URL:https://www.truereviewnow.com/forum/auth/google
OAuth extension:fof/oauth
Web server:Apache / cPanel
Apache domain log:/usr/local/apache/domlogs/truereviewnow.com.ireviewed.in-ssl_log

2. Original Problem

Google login was enabled for Flarum using FoF OAuth.

The login started correctly:

https://www.truereviewnow.com/forum/auth/google

Flarum redirected the user to Google successfully.

But after Google authentication, the browser returned to:

https://www.truereviewnow.com/forum/auth/google?state=...&iss=https%3A%2F%2Faccounts.google.com&code=...&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid&authuser=7&prompt=consent

Instead of completing login, the page showed:

404 Error - Page Not Found

The page was actually a WordPress 404 page, not a Flarum error.

3. Key Finding

The main issue was not:

Google redirect URI mismatch
Flarum config URL mismatch
FoF OAuth not installed
Wrong .htaccess only
Browser cookies only
Session storage only
Google client secret only

The final root cause was:

ModSecurity OWASP CRS rule 930120 was blocking the Google OAuth callback.

Google sends this scope:

https://www.googleapis.com/auth/userinfo.profile

The string:

userinfo.profile

contains:

.profile

ModSecurity interpreted .profile as a possible attempt to access a Unix/Linux local file:

~/.profile

So ModSecurity rule 930120, which detects Local File Inclusion attacks, blocked the callback before normal application handling.

Because the block happened before Flarum could process the request, Apache/cPanel/WordPress behavior resulted in a WordPress-style 404 response.

4. Symptoms Observed

4.1 OAuth Start Route Worked

Command:

curl -skI https://www.truereviewnow.com/forum/auth/google

Expected/observed good output:

HTTP/2 302
x-powered-by: Flarum
set-cookie: flarum_session=...
location: https://accounts.google.com/o/oauth2/v2/auth?...

Meaning:

/forum/auth/google is handled by Flarum correctly.

4.2 Short Callback Worked

Command:

curl -sk "https://www.truereviewnow.com/forum/auth/google?state=test&code=test" | head -n 5

Expected/observed output:

FoF\OAuth\Errors\AuthenticationException: Invalid state

This is a good result.

It means:

The short callback reaches Flarum/FoF OAuth.

The error is expected because state=test is fake.

4.3 Long Google Callback Failed

Command:

curl -skI "https://www.truereviewnow.com/forum/auth/google?state=test&iss=https%3A%2F%2Faccounts.google.com&code=test&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid&authuser=7&prompt=consent"

Bad output:

HTTP/2 404
link: <https://www.truereviewnow.com/wp-json/>; rel="https://api.w.org/"
content-type: text/html; charset=UTF-8

That wp-json header proves the response came from WordPress, not Flarum.

4.4 Browser Callback Failed

Apache log showed:

GET /forum/auth/google HTTP/2.0" 302
GET /forum/auth/google?state=...&iss=https%3A%2F%2Faccounts.google.com&code=...&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+... HTTP/2.0" 404 42117

Meaning:

OAuth start worked.
Google returned correctly.
The callback with long scope parameter failed.

5. Important Misleading Clues

During troubleshooting, several things looked like possible causes but were not the final root cause.

5.1 `.htaccess` Looked Suspicious

Because WordPress was installed at root and Flarum under /forum, the first suspicion was that WordPress was hijacking Flarum pretty URLs.

This was partly valid because WordPress root .htaccess can catch subdirectory routes if not excluded correctly.

A normal WordPress rule like this can be dangerous for Flarum:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

It can cause:

/forum/auth/google

to be handled by WordPress.

So .htaccess still had to be fixed, but it was not the only issue.

5.2 Google Client Secret Looked Suspicious

Changing/regenerating the Google client secret did not fix the WordPress 404.

Why?

Because the callback was not even reaching Flarum in the failing case.

If the request does not reach Flarum/FoF OAuth, the client secret does not matter yet.

5.3 Flarum Session Looked Suspicious

OAuth uses a state parameter and server-side session.

A fake callback returned:

Invalid state

At first this looked like a session issue.

But a proper same-cookie/same-state test proved the session was working.

6. Proper Session/State Test

This test verifies whether Flarum can save and read OAuth state.

cd /home/ireviewed/public_html/forum

rm -f /tmp/flarum_cookie.txt /tmp/flarum_headers.txt /tmp/flarum_callback_headers.txt /tmp/flarum_callback_body.txt

curl -sk \
  -c /tmp/flarum_cookie.txt \
  -D /tmp/flarum_headers.txt \
  https://www.truereviewnow.com/forum/auth/google \
  -o /dev/null

STATE=$(grep -i "^location:" /tmp/flarum_headers.txt | sed -n 's/.*[?&]state=\([^&]*\).*/\1/p' | tr -d '\r')

echo "STATE=$STATE"

curl -sk \
  -b /tmp/flarum_cookie.txt \
  -D /tmp/flarum_callback_headers.txt \
  "https://www.truereviewnow.com/forum/auth/google?state=$STATE&code=test" \
  -o /tmp/flarum_callback_body.txt

cat /tmp/flarum_callback_headers.txt
head -n 120 /tmp/flarum_callback_body.txt

Expected result:

FoF\OAuth\Errors\AuthenticationException: invalid_grant

This is good.

It means:

State validation passed.
Session is working.
Flarum moved to token exchange.

The invalid_grant is expected because code=test is fake.

7. Correct Root `.htaccess` for WordPress + Flarum

Path:

/home/ireviewed/public_html/.htaccess

Backup first:

cp /home/ireviewed/public_html/.htaccess /home/ireviewed/public_html/.htaccess.bak.$(date +%F-%H%M)

Recommended root .htaccess:

# ==========================================================
# ROOT .htaccess
# WordPress: https://www.truereviewnow.com
# Flarum   : https://www.truereviewnow.com/forum
# ==========================================================

DirectoryIndex index.php

<IfModule mod_rewrite.c>
RewriteEngine On

# Preserve Authorization header for PHP apps
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# ----------------------------------------------------------
# Canonical redirects
# ----------------------------------------------------------

# Old domain -> final canonical domain
RewriteCond %{HTTP_HOST} ^(www\.)?ireviewed\.in$ [NC]
RewriteRule ^(.*)$ https://www.truereviewnow.com/$1 [R=301,L]

# Non-www -> www
RewriteCond %{HTTP_HOST} ^truereviewnow\.com$ [NC]
RewriteRule ^(.*)$ https://www.truereviewnow.com/$1 [R=301,L]

# Force HTTPS
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

# ----------------------------------------------------------
# Security
# ----------------------------------------------------------

# Block .git access
RewriteRule (^|/)\.git(/|$) - [F,END]

# ----------------------------------------------------------
# IMPORTANT FLARUM FIX
# Route /forum/* to Flarum BEFORE WordPress can catch it.
# ----------------------------------------------------------

# Block sensitive Flarum files from root level
RewriteRule ^forum/(\.env|auth\.json|composer\.(json|lock)|config\.php|flarum)$ - [F,END]
RewriteRule ^forum/(storage|vendor)(/.*)?$ - [F,END]
RewriteRule ^forum/(.*/)?\.git(/.*)?$ - [F,END]

# Route exact /forum and /forum/ to Flarum
RewriteRule ^forum/?$ /forum/index.php [QSA,END]

# Serve real existing files/folders under /forum normally
RewriteCond %{REQUEST_URI} ^/forum(/|$) [NC]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [END]

# Route all other Flarum pretty URLs to Flarum index.php
RewriteRule ^forum/.*$ /forum/index.php [QSA,END]

</IfModule>

# ----------------------------------------------------------
# Block WordPress XML-RPC
# ----------------------------------------------------------
<Files xmlrpc.php>
  Require all denied
</Files>

# Extra .git protection
RedirectMatch 404 ^(.*/)?\.git+

# BEGIN WordPress
# The directives between "BEGIN WordPress" and "END WordPress"
# are dynamically generated and should only be modified via WordPress filters.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]

# Extra safety: WordPress must never handle /forum
RewriteCond %{REQUEST_URI} !^/forum(/|$) [NC]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

# php -- BEGIN cPanel-generated handler, do not edit
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php82 .php .php8 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

Important note:

[END]

is stronger than:

[L]

[END] stops rewrite processing completely for the current request. This helps prevent WordPress rules from catching Flarum routes in later rewrite passes.

8. Correct Minimal Flarum `.htaccess`

Path:

/home/ireviewed/public_html/forum/.htaccess

Backup first:

cp /home/ireviewed/public_html/forum/.htaccess /home/ireviewed/public_html/forum/.htaccess.bak.$(date +%F-%H%M)

Recommended minimal Flarum .htaccess:

# ==========================================================
# FORUM .htaccess
# Flarum: https://www.truereviewnow.com/forum
# ==========================================================

Options -Indexes
Options -MultiViews

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /forum/

  # Preserve Authorization header
  RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

  # Protect sensitive files/directories
  RewriteRule (^|/)\.git(/|$) - [F,L]
  RewriteRule ^\.env$ - [F,L]
  RewriteRule ^auth\.json$ - [F,L]
  RewriteRule ^composer\.(lock|json)$ - [F,L]
  RewriteRule ^config\.php$ - [F,L]
  RewriteRule ^flarum$ - [F,L]
  RewriteRule ^storage/(.*)?$ - [F,L]
  RewriteRule ^vendor/(.*)?$ - [F,L]

  # Flarum pretty URLs
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^ index.php [QSA,L]
</IfModule>

<IfModule mod_headers.c>
  RequestHeader unset Proxy
</IfModule>

9. Why `.htaccess` Sanitizer Was Not the Final Fix

A sanitizer rule was considered:

RewriteCond %{REQUEST_URI} ^/forum/auth/google$ [NC]
RewriteCond %{QUERY_STRING} (^|&)state=([^&]+).*&code=([^&]+).*&scope= [NC]
RewriteRule ^forum/auth/google$ /forum/auth/google?state=%2&code=%3 [R=302,L,NE]

The idea was to strip Google’s extra parameters and keep only:

state
code

But this did not solve the root problem because ModSecurity was blocking before normal rewrite processing could help.

So the sanitizer was removed.

10. Final Root Cause: ModSecurity Rule 930120

The real blocked value was inside Google’s callback query:

scope=email profile https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email openid

The problematic part:

userinfo.profile

contains:

.profile

OWASP CRS rule 930120 flagged .profile as a possible Local File Inclusion attempt.

This happened before the request reached Flarum.

11. Final ModSecurity Fix

A server-level ModSecurity exclusion was created using cPanel userdata includes.

File:

/etc/apache2/conf.d/userdata/ssl/2_4/ireviewed/truereviewnow.com.ireviewed.in/modsec-flarum.conf

Rule:

SecRule REQUEST_URI "@beginsWith /forum/auth/" \
  "id:1000001,phase:1,nolog,pass,ctl:ruleRemoveTargetById=930120;ARGS:scope"

This removes rule 930120 only for:

ARGS:scope

and only when the URI begins with:

/forum/auth/

This is a safe, narrow fix.

It does not disable ModSecurity globally.

It does not disable the LFI rule for WordPress.

It does not disable the LFI rule for all Flarum requests.

It only excludes the scope argument on Flarum OAuth callback routes.

12. If Both SSL and Non-SSL vhosts Exist

Also create the same file for standard non-SSL userdata if needed:

/etc/apache2/conf.d/userdata/std/2_4/ireviewed/truereviewnow.com.ireviewed.in/modsec-flarum.conf

Same content:

SecRule REQUEST_URI "@beginsWith /forum/auth/" \
  "id:1000001,phase:1,nolog,pass,ctl:ruleRemoveTargetById=930120;ARGS:scope"

13. Rebuild Apache Includes and Restart Apache

After creating userdata include files:

/scripts/ensure_vhost_includes --user=ireviewed
/scripts/restartsrv_httpd

Check syntax:

apachectl -t

Expected:

Syntax OK

14. Verify the ModSecurity Rule Is Loaded

grep -R "1000001\|930120\|ARGS:scope" /etc/apache2/conf.d/userdata/

Expected:

SecRule REQUEST_URI "@beginsWith /forum/auth/" ...
ctl:ruleRemoveTargetById=930120;ARGS:scope

15. Verify Long Callback No Longer Goes to WordPress

Run:

curl -skI "https://www.truereviewnow.com/forum/auth/google?state=test&iss=https%3A%2F%2Faccounts.google.com&code=test&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid&authuser=7&prompt=consent"

Bad output:

HTTP/2 404
link: <https://www.truereviewnow.com/wp-json/>; rel="https://api.w.org/"

Good output should not include:

wp-json

Then run body test:

curl -sk "https://www.truereviewnow.com/forum/auth/google?state=test&iss=https%3A%2F%2Faccounts.google.com&code=test&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid&authuser=7&prompt=consent" | head -n 5

Good fake-test output:

FoF\OAuth\Errors\AuthenticationException: Invalid state

This means the long Google-style callback is reaching Flarum.

16. Real Browser Test

Watch OAuth logs:

LOG=/usr/local/apache/domlogs/truereviewnow.com.ireviewed.in-ssl_log
tail -f $LOG | grep --line-buffered "/forum/auth/google"

Open fresh private/incognito browser:

https://www.truereviewnow.com/forum

Click Google login.

Expected log flow:

GET /forum/auth/google HTTP/2.0" 302
GET /forum/auth/google?state=...&iss=...&code=...&scope=... HTTP/2.0" 302

Bad old flow:

GET /forum/auth/google?state=...&code=...&scope=... HTTP/2.0" 404 42117

If the 404 42117 disappears, ModSecurity issue is fixed.

17. If Real Login Fails After ModSecurity Fix

Once the callback reaches Flarum, new errors may appear.

17.1 `Invalid state`

Meaning:

The browser callback did not send the same Flarum session cookie used when OAuth started.

Check:

Started from correct URL:https://www.truereviewnow.com/forum
Not from:https://truereviewnow.com/forum http://www.truereviewnow.com/forum https://ireviewed.in/forum
Clear cookies for:truereviewnow.com www.truereviewnow.com ireviewed.in
Try incognito.

Check cookie from OAuth start:

curl -skI https://www.truereviewnow.com/forum/auth/google

Expected:

set-cookie: flarum_session=...; Path=/forum; Secure; HttpOnly; SameSite=Lax

17.2 `invalid_grant`

Meaning:

Google rejected the authorization code during token exchange.

Common causes:

Fake/stale/reused code
Wrong client secret
Redirect URI mismatch
Time skew
Code already used
Old browser callback after regenerating secret

Fixes:

Use fresh incognito.
Re-save Google client ID and secret in Flarum.
Confirm redirect URI exactly:https://www.truereviewnow.com/forum/auth/google
Do not use trailing slash.
Do not reuse old callback URL.
Check server time:date timedatectl

17.3 `invalid_client`

Meaning:

Google Client ID or Client Secret is wrong.

Fix:

Go to Google Cloud Console.
Open the OAuth client.
Regenerate client secret.
Update Flarum Admin → FoF OAuth → Google.
Save.
Clear cache:

cd /home/ireviewed/public_html/forum
php flarum cache:clear

17.4 `redirect_uri_mismatch`

Meaning:

Google Console authorized redirect URI does not exactly match what Flarum sends.

Correct value:

https://www.truereviewnow.com/forum/auth/google

Wrong examples:

https://truereviewnow.com/forum/auth/google
http://www.truereviewnow.com/forum/auth/google
https://www.truereviewnow.com/forum/auth/google/

18. Check Flarum Configuration

cd /home/ireviewed/public_html/forum
cat config.php

Important:

'url' => 'https://www.truereviewnow.com/forum',

No trailing slash.

19. Check FoF OAuth

cd /home/ireviewed/public_html/forum

composer show fof/oauth
php flarum info | grep -i oauth

Expected:

fof/oauth
fof-oauth enabled

Enable if needed:

php flarum extension:enable fof-oauth
php flarum cache:clear

20. Check Google OAuth Settings in Flarum

In Flarum Admin:

Admin → Extensions → FoF OAuth → Google

Verify:

Client ID: present
Client Secret: present
Hosted Domain: blank unless intentionally restricted

If a Google secret was exposed, regenerate it.

21. Check Flarum Logs

Flarum logs:

cd /home/ireviewed/public_html/forum
ls -ltr storage/logs/
tail -n 200 storage/logs/*.log

Important note:

If no new Flarum log appears, the request may be blocked before Flarum, for example by:

ModSecurity
Apache vhost config
cPanel rule
WordPress rewrite
CDN/WAF

22. Check Apache Access Logs

Correct cPanel log path in this case:

/usr/local/apache/domlogs/truereviewnow.com.ireviewed.in-ssl_log

Watch OAuth only:

LOG=/usr/local/apache/domlogs/truereviewnow.com.ireviewed.in-ssl_log
tail -f $LOG | grep --line-buffered "/forum/auth/google"

Review previous attempts:

grep "GET /forum/auth/google" /usr/local/apache/domlogs/truereviewnow.com.ireviewed.in-ssl_log | tail -n 30

Important status codes:

302 = redirect / likely normal OAuth flow
404 = likely WordPress or route not found
403 = WAF/ModSecurity/security block
500 = Flarum/PHP exception

In this case, ModSecurity caused behavior that surfaced as WordPress-style 404.

23. Check Apache Error Logs

tail -n 200 /usr/local/apache/logs/error_log

For ModSecurity:

grep -i "930120\|ModSecurity\|userinfo.profile\|/forum/auth/google" /usr/local/apache/logs/error_log | tail -n 50

Also check ModSecurity audit logs if enabled:

grep -Rni "930120\|userinfo.profile\|/forum/auth/google" /var/log/apache2/ /usr/local/apache/logs/ 2>/dev/null | tail -n 100

24. Check Apache Include Files

apachectl -S
apachectl -t

Find cPanel userdata includes:

find /etc/apache2/conf.d/userdata/ -type f | sort

Verify the Flarum ModSecurity exclusion:

grep -R "1000001\|930120\|ARGS:scope" /etc/apache2/conf.d/userdata/

25. File Permission Checks

Flarum needs writable storage:

cd /home/ireviewed/public_html/forum

ls -ld storage storage/sessions storage/cache storage/logs
find storage -maxdepth 2 -type d -exec ls -ld {} \;

Fix if needed:

cd /home/ireviewed/public_html/forum

mkdir -p storage/sessions storage/cache storage/logs
chown -R ireviewed:ireviewed storage
chmod -R 775 storage

php flarum cache:clear

Restrict config.php:

cd /home/ireviewed/public_html/forum

chown ireviewed:ireviewed config.php
chmod 640 config.php

26. Debug Mode

Enable temporarily:

'debug' => true,

Then:

cd /home/ireviewed/public_html/forum
php flarum cache:clear

Disable after fixing:

'debug' => false,

Then:

php flarum cache:clear

Never leave debug enabled on production.

27. Clean Testing Procedure

Use this exact sequence.

Step 1: Confirm Flarum route

curl -skI https://www.truereviewnow.com/forum/auth/google

Expected:

HTTP/2 302
x-powered-by: Flarum
location: https://accounts.google.com/...

Step 2: Confirm short fake callback

curl -sk "https://www.truereviewnow.com/forum/auth/google?state=test&code=test" | head -n 5

Expected:

FoF\OAuth\Errors\AuthenticationException: Invalid state

Step 3: Confirm long Google-style fake callback

curl -sk "https://www.truereviewnow.com/forum/auth/google?state=test&iss=https%3A%2F%2Faccounts.google.com&code=test&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid&authuser=7&prompt=consent" | head -n 5

Expected after ModSecurity fix:

FoF\OAuth\Errors\AuthenticationException: Invalid state

Bad:

<!DOCTYPE html>
<html lang="en-US">

or:

wp-json

Step 4: Real browser test

LOG=/usr/local/apache/domlogs/truereviewnow.com.ireviewed.in-ssl_log
tail -f $LOG | grep --line-buffered "/forum/auth/google"

Then try login.

28. Final Security Notes

28.1 Rotate Google OAuth Secret

If the Google OAuth client secret was pasted into chat, screenshots, logs, or shared with third-party tools, regenerate it.

Then update:

Flarum Admin → FoF OAuth → Google

Clear cache:

cd /home/ireviewed/public_html/forum
php flarum cache:clear

28.2 Protect config.php

Flarum stores DB credentials in config.php.

Recommended:

cd /home/ireviewed/public_html/forum
chmod 640 config.php
chown ireviewed:ireviewed config.php

28.3 Do Not Disable ModSecurity Globally

Do not use broad fixes like:

SecRuleEngine Off

Do not disable ModSecurity for the full domain.

Do not disable rule 930120 globally.

Use narrow exclusion:

ctl:ruleRemoveTargetById=930120;ARGS:scope

only for:

/forum/auth/

29. Final Diagnosis Summary

The issue looked like:

Google OAuth / Flarum / .htaccess / WordPress routing problem

But the true root cause was:

ModSecurity OWASP CRS rule 930120 flagged Google OAuth's scope parameter because it contained userinfo.profile, which includes .profile.

That block prevented the long Google callback from reaching Flarum.

Short callbacks worked because they did not contain:

scope=...userinfo.profile...

The final fix was a narrow server-level ModSecurity exclusion:

SecRule REQUEST_URI "@beginsWith /forum/auth/" \
  "id:1000001,phase:1,nolog,pass,ctl:ruleRemoveTargetById=930120;ARGS:scope"

Then rebuild Apache includes and restart Apache:

/scripts/ensure_vhost_includes --user=ireviewed
/scripts/restartsrv_httpd

Finally disable Flarum debug mode after successful test.

30. Golden Troubleshooting Lesson

When OAuth works for the start URL but fails only after provider callback, always compare:

short fake callback
long real provider callback

If the short callback reaches the app but the long callback does not, inspect:

WAF
ModSecurity
encoded URL values inside query string
suspicious parameter names/values
provider-specific scopes
Apache error/audit logs

In this case, the entire issue came down to:

userinfo.profile

being misread as:

.profile

by a Local File Inclusion rule.

rajeshkumar

Uncategorized

Simplifying the Search for Trusted Professionals Near Me

digitalguru · June 19, 2026 · 0 Comment

Introduction We live in an era where you can manage almost your entire life from a smartphone, yet finding reliable local help often feels stuck in the…

Uncategorized

Complete AIOps Training Guide: Tools, Use Cases, Certification & Career Path

digitalguru · June 19, 2026 · 0 Comment

Modern enterprise infrastructure generates far more data than human operators can realistically process. A typical cloud-native architecture experiences hundreds of thousands of ephemeral events daily, leading to…

Uncategorized

Helps Businesses Establish, Grow, and Scale Their Online Presence

digitalguru · June 18, 2026 · 0 Comment

In the modern marketplace, a strong online presence is the primary engine for customer acquisition, brand reputation, and revenue growth. With over 81% of consumers researching brands…

Uncategorized

Business Website Development Guide: From Planning to Launch

digitalguru · June 17, 2026 · 0 Comment

Introduction In the modern hyper-digital marketplace, a professional website development strategy functions as the primary engine for business scalability, brand credibility, and customer acquisition. Businesses operating without…

Uncategorized

Smarter Medical Travel Planning with MyMedicPlus Healthcare Assistance

digitalguru · June 12, 2026 · 0 Comment

Navigating the international medical landscape can often feel like an overwhelming, uphill battle for individuals seeking specialized clinical treatment. Fortunately, the emergence of advanced digital health ecosystems…

Uncategorized

Smarter Hospital Selection With MyHospitalNow and Cost Transparency

digitalguru · June 12, 2026 · 0 Comment

Introduction Imagine sitting at your kitchen table late at night, staring at a medical diagnosis or a recommendation for an upcoming surgery. Your mind immediately floods with…

$100 Website Offer

1. Environment Overview

2. Original Problem

3. Key Finding

4. Symptoms Observed

4.1 OAuth Start Route Worked

4.2 Short Callback Worked

4.3 Long Google Callback Failed

4.4 Browser Callback Failed

5. Important Misleading Clues

5.1 .htaccess Looked Suspicious

5.2 Google Client Secret Looked Suspicious

5.3 Flarum Session Looked Suspicious

6. Proper Session/State Test

7. Correct Root .htaccess for WordPress + Flarum

8. Correct Minimal Flarum .htaccess

9. Why .htaccess Sanitizer Was Not the Final Fix

10. Final Root Cause: ModSecurity Rule 930120

11. Final ModSecurity Fix

12. If Both SSL and Non-SSL vhosts Exist

13. Rebuild Apache Includes and Restart Apache

14. Verify the ModSecurity Rule Is Loaded

15. Verify Long Callback No Longer Goes to WordPress

16. Real Browser Test

17. If Real Login Fails After ModSecurity Fix

17.1 Invalid state

17.2 invalid_grant

17.3 invalid_client

17.4 redirect_uri_mismatch

18. Check Flarum Configuration

19. Check FoF OAuth

20. Check Google OAuth Settings in Flarum

21. Check Flarum Logs

22. Check Apache Access Logs

23. Check Apache Error Logs

24. Check Apache Include Files

25. File Permission Checks

26. Debug Mode

27. Clean Testing Procedure

Step 1: Confirm Flarum route

Step 2: Confirm short fake callback

Step 3: Confirm long Google-style fake callback

Step 4: Real browser test

28. Final Security Notes

28.1 Rotate Google OAuth Secret

28.2 Protect config.php

28.3 Do Not Disable ModSecurity Globally

29. Final Diagnosis Summary

30. Golden Troubleshooting Lesson

Related Posts

Simplifying the Search for Trusted Professionals Near Me

Complete AIOps Training Guide: Tools, Use Cases, Certification & Career Path

Helps Businesses Establish, Grow, and Scale Their Online Presence

Business Website Development Guide: From Planning to Launch

Smarter Medical Travel Planning with MyMedicPlus Healthcare Assistance

Smarter Hospital Selection With MyHospitalNow and Cost Transparency

5.1 `.htaccess` Looked Suspicious

7. Correct Root `.htaccess` for WordPress + Flarum

8. Correct Minimal Flarum `.htaccess`

9. Why `.htaccess` Sanitizer Was Not the Final Fix

17.1 `Invalid state`

17.2 `invalid_grant`

17.3 `invalid_client`

17.4 `redirect_uri_mismatch`