Uncategorized

When building GreenRobot Job Search, we needed to test multiple subdomains locally — aicareers.greenrobot.com for AI/ML jobs and remotedevjobs.greenrobot.com for remote developer positions. Each subdomain shares the same codebase but serves filtered content with its own branding. The challenge? Getting Google OAuth and shared sessions to work across subdomains in local development.

The Problem

In production, session sharing across subdomains is straightforward. You set your PHP session cookie domain to .greenrobot.com, and all subdomains — jobsearch, aicareers, remotedevjobs — share the same login session. Simple.

Local development is a different story. Our main site runs on localhost because that’s what’s registered as an authorized redirect URI in Google Cloud Console for OAuth. But subdomains like aicareers.local or aicareers.localhost are on completely different domains — browsers won’t share cookies between localhost and aicareers.local.

We tried several approaches:

• *.local domains — Can’t share cookies with localhost. Different domain entirely.
• *.localhost domains — RFC 6761 says these should resolve to 127.0.0.1, and they do. But localhost is on the browser’s Public Suffix List, which means browsers block cookies set with domain=.localhost. Session sharing is impossible.
• Registering jobsearch.localhost with Google OAuth — Google rejects it. Their redirect URI validation requires a public top-level domain like .com or .org. The .localhost TLD is not accepted.

The Solution: lvh.me

lvh.me is a free domain that resolves to 127.0.0.1 — including all subdomains. No /etc/hosts changes required:

$ ping jobsearch.lvh.me
PING jobsearch.lvh.me (127.0.0.1)

$ ping aicareers.lvh.me
PING aicareers.lvh.me (127.0.0.1)

Because .me is a real public TLD, everything just works:

1. Google OAuth accepts it — http://jobsearch.lvh.me/auth/google-callback.php is a valid redirect URI.
2. Cookie sharing works — Setting domain=.lvh.me on the session cookie lets jobsearch.lvh.me, aicareers.lvh.me, and remotedevjobs.lvh.me share the same PHP session.
3. No DNS configuration — All *.lvh.me subdomains resolve to 127.0.0.1 out of the box.

Implementation

The PHP side is minimal. In our session configuration:

$currentHost = strtolower($_SERVER['HTTP_HOST'] ?? '');
$hostNoPort = preg_replace('/:\d+$/', '', $currentHost);

$cookieDomain = '';
if (preg_match('/\.greenrobot\.com$/', $hostNoPort)) {
    // Production: share across *.greenrobot.com
    $cookieDomain = '.greenrobot.com';
} elseif (preg_match('/(^|\.)lvh\.me$/', $hostNoPort)) {
    // Local dev: share across *.lvh.me
    $cookieDomain = '.lvh.me';
}

session_set_cookie_params([
    'domain' => $cookieDomain ?: '',
    'path' => '/',
    'httponly' => true,
    'samesite' => 'Lax',
]);

Our subdomain detection code doesn’t need to know about lvh.me specifically — it just checks the hostname prefix:

if (preg_match('/^aicareers\./', $host)) {
    // Serve AI Careers content
} elseif (preg_match('/^remotedevjobs\./', $host)) {
    // Serve Remote Dev Jobs content
}

This matches aicareers.greenrobot.com in production and aicareers.lvh.me in development with the same code.

For Apache, we added the lvh.me subdomains as aliases to our existing vhost:

<VirtualHost *:80>
    ServerName jobsearch.local
    ServerAlias jobsearch.lvh.me aicareers.lvh.me remotedevjobs.lvh.me
    DocumentRoot "/path/to/public_html"
</VirtualHost>

The Login Flow

1. User visits http://aicareers.lvh.me/
2. Clicks Login — redirected to http://jobsearch.lvh.me/auth/login.php?return_to=http://aicareers.lvh.me/
3. Authenticates via Google OAuth (callback registered on jobsearch.lvh.me)
4. Session cookie set with domain=.lvh.me
5. Redirected back to http://aicareers.lvh.me/ — already logged in because the session cookie is shared

Takeaway

If you’re building a multi-subdomain app and need to test OAuth and shared sessions locally, skip the localhost/.local headaches and use lvh.me. It’s a zero-configuration solution that plays nicely with Google’s OAuth restrictions and browser cookie policies.

We recently added WCAG 2 AA accessibility testing to our CI pipeline at GreenRobot Job Search using pa11y. After fixing dozens of real issues in our own code – contrast ratios, missing form labels, empty anchor tags – we got every page on our site to zero accessibility errors.

Then we opened a pull request.

Our GitHub Actions CI pipeline ran pa11y against the live site – and every single page with Google AdSense failed.

The Problem

Google AdSense injects iframes into your page at runtime with no title attribute:

[iframe src="https://www.google.com/recaptcha/api2/aframe"
        width="0" height="0"
        style="display: none;">[/iframe>

[iframe id="google_esf" name="google_esf"
        src="https://googleads.g.doubleclick.net/pagead/html/..."
        style="display: none;">[/iframe>

(note less than sign replaced with [ so it renders code in the blog. gotta fix this one day)

This violates WCAG 2.4.1 (Bypass Blocks) and WCAG 4.1.2 (Name, Role, Value). Every iframe needs a non-empty title attribute so screen reader users can identify its purpose.

The fix would be trivial on Google’s end. Something like:

[iframe title="Google ad services" ...>[/iframe>

That’s it. One attribute.

Why This Matters

If you’re a developer trying to make your site accessible – and you should be – Google’s ad scripts will fail your automated accessibility tests through no fault of your own. You’re left with two options:

1. Exclude Google’s iframes from your tests (what we had to do)
2. Remove ads from your site

Neither option is great. The first means you’re sweeping a real accessibility violation under the rug. The second means giving up revenue because a trillion-dollar company couldn’t add a title attribute to an iframe.

Here’s the pa11y ignore rule we had to add to our CI config:

{
  "defaults": {
    "hideElements": "iframe[src*='google'], iframe[src*='doubleclick'], iframe[src*='recaptcha']"
  }
}

We shouldn’t have to do this.

The Bigger Picture

Google has published extensive accessibility guidelines and Chrome DevTools has built-in accessibility auditing via Lighthouse. Google literally built tools to catch this exact problem. Yet their own ad platform ships inaccessible markup to millions of websites.

This isn’t just a Google problem. The entire ad-tech ecosystem largely ignores accessibility. Ad iframes routinely lack titles, ad content rarely meets contrast requirements, and interactive ad elements often aren’t keyboard-navigable. But Google sets the standard. If AdSense shipped accessible markup, the industry would follow.

A Call to Action

To Google: Please add title attributes to the iframes your ad scripts inject. It’s a one-line fix that would instantly improve accessibility across millions of websites.

To ad-tech competitors: There’s a real opportunity here. If you’re building an ad platform that competes with AdSense, ship accessible markup by default. Make it a selling point. As accessibility regulations tighten globally – the European Accessibility Act took effect in June 2025 – publishers will increasingly need ad partners that don’t break their compliance.

To fellow developers: Don’t let third-party scripts be an excuse to skip accessibility testing. Add the ignore rules you need to keep your CI green, but document why those rules exist. File bugs with the offending services. And keep testing the code you can control.

We got our site from 91 accessibility errors down to zero across 16 pages. The only failures left are Google’s, not ours. We’ll keep the ignore rules in place for now, but we’d love nothing more than to remove them.

Andy Triboletti is the founder of GreenRobot. GreenRobot Job Search helps developers find jobs at VC-backed companies. Our codebase is tested with pa11y (WCAG 2 AA), Nu HTML Checker, and Puppeteer console error detection on every pull request.