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.

Monday, August 18, 2025

HCL Software Pricing Update: 6-9% Increases Effective Today (Aug 18, 2025)

HCL Software just implemented their new renewal pricing policy today with specific percentage increases across their product portfolio. Here's the breakdown:

Pricing Structure:

  • Perpetual License/S&S: 9% increase
  • Term & Other License types: 6% increase

Products Affected (all following above structure):

  • AppScan, BigFix, Commerce
  • Digital Solutions (Domino, Sametime, Leap, Connections, Volt MX Go)
  • Digital Experience (DX), Unica, Volt MX
  • Workload Automation, Secure DevOps & Mainframe products

Key Details:

  • Effective immediately on new software price lists
  • Late renewals will be backdated with additional fees
  • Migration from Perpetual to Term licenses may have promotional offers
  • Multi-year commitments can access additional promotional pricing

Source: HCL Support KB article KB0121452

Thursday, July 10, 2025

XPages Rendering Issue to Be Fixed in Domino 14.5 FP1

If you’ve recently upgraded your Domino server to version 14.5, and you’re working with XPages, you may have encountered a frustrating issue: broken rendering in certain views or components. This bug has been affecting a number of applications, particularly those that rely on partial refresh or dynamically rendered controls.

HCL has officially acknowledged this issue and published a knowledge base article detailing the problem. According to the article (KB0122228), the issue is caused by a regression introduced in recent versions of the XPages runtime, and it affects how JavaScript resources are handled during page rendering.

Good news: a fix is coming soon!

HCL plans to resolve this issue in Domino 14.5 Fix Pack 1 (FP1). If you're running into problems with XPages after upgrading, you’ll want to keep an eye out for this upcoming fix pack.

In the meantime, if your applications are mission-critical and you're stuck with broken UI elements, consider temporarily rolling back to a stable version or using workarounds such as disabling dynamic rendering or tweaking partial refresh logic where possible.

Wednesday, April 02, 2025

Generating PDF Documents in Domino Using PD4ML Java Library

Generating PDF documents from web content or structured data is a common requirement in many applications. When working with HCL Domino, we often need to create PDFs from HTML templates, Notes documents, or dynamically generated content. In this article, I'll walk you through using the PD4ML Java library to generate PDFs within a Domino Java Agent.

Why Use PD4ML?

PD4ML is a powerful Java library that allows you to convert HTML and CSS into high-quality PDF documents. It supports:

  • CSS styling
  • Page breaks and headers/footers
  • Embedded images
  • Table of contents and bookmarks
  • Various output formats (A4, Letter, etc.)

This makes it a great choice for generating invoices, reports, or any structured documents from Domino applications.

Setting Up PD4ML in Domino

To use PD4ML in your Domino environment, follow these steps:

1. Download PD4ML

Get the PD4ML JAR from pd4ml.com. You can use the free or commercial version, depending on your needs.

2. Add PD4ML to Your Domino Project

  1. Place the PD4ML JAR file in the jvm/lib/ext directory of your Domino server (if you want it available for all agents) or within your NSF under WEB-INF/lib (if used in an XPages app).
  2. If using a Java agent, attach the JAR to the agent's Build Path (I usually create a dedicated Java library for external JARs).

3. Write a Java Agent to Generate a PDF

Below is just a snippet to get an idea what you need to do in your Domino Java Agent. The example takes an HTML string and converts it into a PDF:

PD4ML pd4ml = new PD4ML();

String html = "TEST <b>Hello, World!</b>";
ByteArrayInputStream bais = new ByteArrayInputStream(html.getBytes());

// read and parse HTML
pd4ml.readHTML(bais);

File pdf = File.createTempFile("result", ".pdf");
FileOutputStream fos = new FileOutputStream(pdf);

// render and write the result as PDF
pd4ml.writePDF(fos);

PD4ML and HCL Notes/Domino

PD4ML claims they provide support for converting HCL Notes documents into PDFs (I have never checked it though), making it an ideal solution for Domino applications.

Using PD4ML in HCL Domino makes PDF generation straightforward. Whether you need to create reports, invoices, or structured documents, this Java library is a flexible and efficient solution. Try it out in your Domino projects and let me know if you run into any issues!

I have previously used iText and Apache PDFBox for generating PDFs in Domino, as well as various external tools that convert HTML files into PDFs. However, I found PD4ML to be the most user-friendly solution due to its seamless integration with HTML and CSS, built-in support for page formatting, and its ability to handle embedded images and styles with minimal effort.


What tools or libraries do you use in your Domino applications to build PDF files?

Tuesday, September 17, 2024

Implementing SSO Authentication with Saml Using LotusScript & Java

Introduction

SAML (Security Assertion Markup Language) is a widely used protocol for Single Sign-On (SSO), allowing users to authenticate once and access multiple applications. In this article, we'll walk through implementing SAML authentication in a Domino application, detailing the steps needed to provide metadata, make the SSO call, and handle the assertion response (ACS call).

Prerequisites

Before you begin, ensure you have:

  • Access to a SAML Identity Provider (IdP) such as Microsoft Azure AD or Okta.
  • Basic knowledge of Java and HTTP requests.
  • A configured Domino server with the capability to execute Java agents.

Step-by-Step Implementation

1. Providing Metadata

The first step in setting up SAML authentication is to provide metadata that the Identity Provider (IdP) and Service Provider (SP) can use for configuration. You’ll need to supply both IdP and SP metadata to the Domino application.

Basically it means you will need to make 2 public URL: https://yourdomain.com/meta/{id} that provide XML response (and that will be used by IdP) and additionally to that IdP sohuld provide their URL you are going work with.

You also need to find a suitable Java library that can provide your a SamlClient (I use https://github.com/lastpass/saml-sdk-java)

2. Making the SSO Call

Once the metadata is set, you can make the SSO request to the IdP. Here’s the code that generates the SAML authentication request and sends it to the IdP.

String idpURL = config.getItemValueString("IdPURL");
idpMeta = new URL(idpURL).openStream();

String spData = config.getItemValueString("MetaXML");
spMeta = new ByteArrayInputStream(spData.getBytes(StandardCharsets.UTF_8));

// 2. initialize saml client
SAMLInit.initialize();
IdPConfig idpConfig = new IdPConfig(idpMeta);
SPConfig spConfig = new SPConfig(spMeta);
SAMLClient client = new SAMLClient(spConfig, idpConfig);

// 3. send login request
String requestId = SAMLUtils.generateRequestId();
String authrequest = client.generateAuthnRequest(requestId);
String url = client.getIdPConfig().getLoginUrl() + "?SAMLRequest=" + URLEncoder.encode(authrequest, "UTF-8");

The SAMLClient is used to generate the authentication request, and the resulting URL is the login endpoint where the user must be redirected.

3. Handling the Assertion Consumer Service (ACS) Call

After the user is authenticated by the IdP, the SAML response is sent back to the Domino server via the Assertion Consumer Service (ACS) endpoint. The following code handles this response and extracts user attributes from it.

String authresponse = web.getParam("AuthResponse");
String idpURL = config.getItemValueString("IdPURL");
String spData = config.getItemValueString("MetaXML");

SAMLInit.initialize();
IdPConfig idpConfig = new IdPConfig(idpMeta);
SPConfig spConfig = new SPConfig(spMeta);
SAMLClient client = new SAMLClient(spConfig, idpConfig);

AttributeSet aset = client.validateResponse(authresponse);
Map> attr = aset.getAttributes();
for (Map.Entry> entry : attr.entrySet()) {
    String key = entry.getKey();
    List values = entry.getValue();
    doc.replaceItemValue(key, new Vector<>(values));
}

This code validates the SAML response using the SAMLClient, extracts the attributes (such as username, email, etc.), and stores them in the Domino document.

Conclusion

Implementing SAML authentication in Domino involves configuring metadata for the IdP and SP, making an authentication request, and handling the ACS call to process the response. While this example uses the LastPass SAML library, similar methods apply when using other libraries. The overall process is straightforward and can greatly improve the security and convenience of user authentication in your Domino applications.