Unable to getUser() after logging into a PHP 7.4 Regular Application with a Subdomain

Hi all,

I’m currently following the Quickstart PHP guide for setting up Auth0 for my website. Everything is run off an Apache/2.4.6 server with PHP 7.4, and I have a custom domain for my login. All dependencies were installed using composer require auth0/auth0-php:"~7.0"

The sample PHP code can be found here:

I’m able to successfully process both logins and new registrations, and my callback URL points back to my index page. The require statement points to the correct directory for autoload.php, and loads fine. However, my code breaks at the getUser() command.

require __DIR__ . 'vendor/autoload.php';
            
use Auth0\SDK\Auth0;

$auth0 = new Auth0([
'domain' => '**********',
'client_id' => '**********',
'client_secret' => '**********',
'redirect_uri' => '**********',
'scope' => 'openid profile email',
]);

$userInfo = $auth0->getUser();

if (!$userInfo) {
	// Redirect to the login page
} else {
	// Only show page for logged in users
}

I’d love some help, as I haven’t any idea why that’s failing on my end. I ran a search across the forum and most users with a similar issue had Safari issues, whereas mine breaks on most browsers.

Thanks,
Nick

=====EDIT=====

Looks like this problem only occurs when using subdomains on my site, especially when used as my redirect. For example, the below configuration works as intended:

Custom Domain: https://auth.example.com
Login Page: https://example.com/login.php
Redirect Page: https://example.com/explore/app/index.php


In my scenario, I’m using my /explore/ folder as a subdomain, and a .htaccess rewrite to advance in the /explore/ folder when viewing the subdomain page, so that it doesn’t appear in my URL. Here’s how it looks behind the scenes:

https://example.com/explore/app/index.php => https://explore.example.com/app/index.php

RewriteEngine On
RewriteCond %{HTTP_HOST} ^explore\.example\.com$
RewriteCond %{REQUEST_URI} !^/explore/
RewriteRule (.*) /explore/$1

With this setup, I have the following:

Custom Domain: https://auth.example.com
Login Page: https://example.com/login.php
Redirect Page: https://explore.example.com/app/index.php

Apparently Auth0 fails to recognize the user session when using a subdomain. Is there anything I can do for the subdomain to recognize that session? At this point I’m not sure if that’d imply an additional .htaccess rule or PHP / JS modification. I do however have https://explore.example.com/app/ as an allowed callback URL & logout URL under my application settings.

Even more updates (sorry for the triple post).

It seems even after removing the .htaccess rule and eliminating that variable, redirects using a “www” subdomain fail as well, whereas https://example.com/explore/app/ redirects (without any subdomain) work without issue. So let’s work with the www subdomain for now.

I’d added a wildcard to my Allowed Callback & Logout URLs under my Application settings page (https://*.example.com/explore/app/), then added https://www.example.com/explore/app/ to 'redirect_uri' in my index.php & login.php PHP files, yet still have no luck reading the getUser() info. To reiterate, these pages work fine without any sort of subdomain (explore.example.com or www.example.com).

Might I add that I also have the example.com A name, as well as the “www” and “explore” CNAMEs proxied through Cloudflare. I’d temporarily changed the Proxy status to DNS only, yet still unable to read while using the www subdomain on my page. My Auth0 custom login domain however works fine under Cloudflare when added as a CNAME with proxy disabled (DNS only).

1 Like

Hey all,

It looks like I was able to resolve this issue after working with the support team. I’d noticed if I accessed my login.php page from the same subdomain as my web page, by adding ‘www’, I was then able to access my main site also on the ‘www’ subdomain. Now moving my login.php file to the ‘explore’ subdomain worked as well.

So in summary, my Application Login URL has to be on the same subdomain as my main site. All works fine now! Marking this as the solution if anyone else stumbles across this in the future.

2 Likes

Thanks for sharing it with the rest of community!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.