enhancement
major
minor
defect
critical
major
minor
major
#30179
An application generated with useSSO=true offers the generic OpenID login, switched on by the tl_pac_* environment variables, also on the development server
Problem
The archetype tl-archetype-app has the property useSSO. It only adds the dependency tl-security-auth-pac4j to the generated POM. The module's metaConf.txt loads tlPac4jConf.xml only. The generic OpenID Connect client (pac4j-generic.xml / pac4j-generic.config.xml, reading tl_pac_discovery_uri, tl_pac_client_id, tl_pac_scope, tl_pac_secret) is switched on by the profile with-openid-generic of tl-parent-app. That profile acts only on the built WAR (tl.app.metaConfAddons.*, TLAppWar).
As a result, an application generated with useSSO=true and started on the development server (exec:java, deploy/local) has no generic OpenID login, even when every tl_pac_* variable is set. In addition, pac4j-generic.xml defines %PAC_DISCOVERY_URI% as ${env:tl_pac_discovery_uri} without a default, so enabling it unconditionally is not harmless.
The control application tl-factory generates its projects with this archetype and wants every new project to log in through an OpenID provider whose settings the workspace passes as tl_pac_* variables. Without these variables, for example after deployment, no button should be offered (Gitea issue TopLogic/tl-factory#47).
Design
- With useSSO=true, the generated application enables the generic client itself: its own metaConf.txt references pac4j-generic.xml, so the development server and the WAR behave the same.
- The generic client is harmless without its variables. Every alias of pac4j-generic.xml has a default (empty discovery URI, empty secret), the application starts without errors, and the login page offers no button while tl_pac_secret is missing. A secret without discovery URI is ticket:30173.
- The label of the button is a setting as well (e.g. tl_pac_label), with a neutral default.
- The article application-project describes useSSO and the variables.
Acceptance
- An application generated with useSSO=true starts on the development server without any tl_pac_* variable, without errors and without an OpenID button.
- With tl_pac_discovery_uri, tl_pac_client_id and tl_pac_secret set, the login page offers the button with the configured label, and the login completes against a provider (e.g. Keycloak through its discovery URI).
- The WAR of such an application behaves the same.
- useSSO=false generates no pac4j configuration, as before.
Lösung
- com.top_logic.security.auth.pac4j: every alias of pac4j-generic.xml and the shared aliases of tlPac4jConf.xml get an explicit default (${env:...:}), so a start without the variables logs no missing variable. The generic client gets the label %PAC_LABEL% from tl_pac_label; an empty label falls back to a translated default of the module ("Log in with single sign-on" / "Mit Single Sign-on anmelden"), no longer to the technical client name. An empty scope is passed to pac4j as not set, so its default scope applies.
- tl-archetype-app: with useSSO=true, the application's src/main/webapp/WEB-INF/conf/metaConf.txt references pac4j-generic.xml. This one entry enables the client on the development server and in the WAR; no build profile and no deploy/local entry is needed. useSSO=false generates no such entry.
- The article application-project describes useSSO with the variables tl_pac_discovery_uri, tl_pac_client_id, tl_pac_secret, tl_pac_scope, tl_pac_label.
- Out of scope: the provider-specific profiles (Keycloak, Azure, Google).