Monday, February 23, 2026

Custom Login Database Resources Blocked on Domino OIDC Provider? Use HTTPPublicURLs

When you configure HCL Domino as an OIDC Provider, the Internet Site document requires Anonymous = No on TLS security settings. This is by design — the OIDC Provider needs to enforce authentication on all incoming requests so it can properly handle the authorization code flow.

If your login workflow uses a custom database (anything other than domcfg.nsf), you'll run into an unexpected problem.

The Problem

The login form itself loads fine — Domino's HTTP engine hardcodes exceptions for domcfg.nsf, ?Login, ?Logout, and /auth/protocol/oidc/* endpoints. So domcfg.nsf successfully redirects the user to your custom login page.

But all the resources your form depends on in a separate database — agents, images, CSS, JavaScript, AJAX calls — get intercepted and redirected to the OIDC authorization endpoint instead of being served. The browser receives a 302 redirect to something like:

https://your-server.com/auth/protocol/oidc/auth?scope=openid&state=...&redirect_uri=...

The result: the login form renders, but it's broken. No styles, no images, no functioning server calls. The user can see the form but can't actually authenticate. Your Java agents return OIDC redirects instead of JSON responses. Your AJAX calls fail silently.

This affects any deployment where the login flow pulls resources from a database other than domcfg.nsf — multi-step authentication forms, custom branding portals, or any application that acts as a front-end to the Domino login process.

The Fix: HTTPPublicURLs

Domino has a notes.ini parameter called HTTPPublicURLs that allows specific URL paths to bypass authentication enforcement — even when Anonymous = No is set on the Internet Site.

Add your login database path to it in notes.ini:

HTTPPublicURLs=/iwaredir.nsf/*:/.well-known*:/yourlogin.nsf/*

Paths are separated by colons (:). Wildcard (*) at the end matches everything under that prefix. Replace /yourlogin.nsf/* with your actual database path. Then restart the HTTP task:

restart task http

After that, all resources in your custom login database — pages, agents, images, stylesheets, scripts, AJAX endpoints — become accessible without triggering OIDC redirects. Everything else on the server stays protected.

No code changes, no DSAPI filters, no reverse proxy, no second hostname — just one line in notes.ini.

No comments :