Azure Single Sign-On loading issue with version 0.43 and higher

[htnotc]

Hello,

I am using Microsoft Azure with OpenID Connect (OIDC). With version 0.42, everything works flawlessly but from the moment I upgrade to version 0.43 or higher, my homepage (index.sql) never loads and the browser keeps on spinning forever (in Chrome and Edge). I tried clearing my cookies but the issue remains. Did any parameter name changed in version 0.43?

These are the parameters I used in my sqlpage.json:
{
"database_url": "mssql://database_connection_string",
"content_security_policy": "",
"oidc_issuer_url": "https://login.microsoftonline.com/tenant_id/v2.0",
"oidc_client_id": "oidc_client_id_value",
"oidc_client_secret": "oidc_client_secret_value",
"host": "host_url",
"site_prefix": "/",
"oidc_protected_paths": ["/"]
}

Thanks in advance!

[lovasoa]

Hi ! Thank you very much for reporting this. Let's try to debug this.

Could you please confirm first that 0.42 and 0.43+ were tested under the exact same conditions: same Azure deployment, same hostname, same reverse proxy, same Microsoft Entra app registration, same redirect URI, from the same server and around the same time?

Then could you please send privately (to contact @ ophir.dev):

1. A browser HAR for one failing login attempt with the latest sqlpage version (0.44.1):

• Open a private/InPrivate window.
• Open DevTools -> Network.
• Enable “Preserve log”.
• Navigate to the homepage.
• Let it spin for 20-30 seconds.
• Export “Save all as HAR with content”.

2. SQLPage logs for the same attempt. For SQLPage 0.44.x or newer:

LOG_LEVEL=sqlpage::webserver::oidc=debug,sqlpage=info,sqlpage::access=info

The most useful lines are around:

• OIDC redirect URL
• Redirecting to OIDC provider
• Processing OIDC callback
• Failed to process OIDC callback
• Failed to exchange code for token
• Could not verify the ID token
• No sqlpage_oidc_state... cookie found
• No sqlpage_oidc_nonce cookie found
• successfully logged in

The HAR and debug logs can contain sensitive cookies, authorization codes, or tokens. Please do not post these publicly. If you understand how to triage them, you can post the raw censored logs here, otherwise send them privately to contact@ophir.dev if they contain sensitive information.

We are especially looking for whether the network trace repeats this pattern:

/ -> Microsoft login -> /sqlpage/oidc_callback -> / -> Microsoft login -> ...

or whether one request, especially /sqlpage/oidc_callback, remains pending or returns an error.

[lovasoa]

We tried to reproduce this with Microsoft Entra ID and the official GitHub release binaries, but we could not reproduce the failure: both v0.42.0 and v0.43.0 logged in successfully and served the homepage.

So this does not look like a simple parameter rename or a universal Entra ID regression in 0.43.0. Could you compare your setup with the repro below and tell us exactly what you are doing differently from us? The most useful differences would be: hosting environment, SQLPage binary/container source, OS/architecture, host, site_prefix, reverse proxy / Azure App Service / HTTPS termination, registered redirect URI, and whether the issue still happens with a minimal index.sql.

If you collect a HAR or verbose OIDC logs, please do not paste secrets, authorization codes, cookies, access tokens, or ID tokens publicly. You can send sensitive files privately to contact@ophir.dev.

Local Entra repro we ran

We used a local repro, not a source build.

Release artifacts:

• v0.42.0: downloaded sqlpage-macos.tgz from the GitHub release
• v0.43.0: downloaded sqlpage-macos.tgz from the GitHub release
• v0.42.0 archive sha256: 0428222c21ec16e2bef861e6c55260e58ed97cbf70ad8b3265d381ef531d266f
• v0.43.0 archive sha256: 98b2ec9f678e0fee1ee632e96f2e21b52c31e303482d547045378e7af955aebd
• Both binaries reported the expected version with --version.

Entra app setup:

• OIDC issuer: https://login.microsoftonline.com/<tenant-id>/v2.0
• Redirect URI registered in Entra: http://localhost:8080/sqlpage/oidc_callback
• Platform type: Web
• Client secret used, but not written to the config file here

SQLPage config used, with secrets redacted:

{
  "listen_on": "127.0.0.1:8080",
  "database_url": "sqlite:///private/tmp/sqlpage-entra-repro/sqlpage.db?mode=rwc",
  "content_security_policy": "",
  "host": "localhost:8080",
  "site_prefix": "/",
  "oidc_issuer_url": "https://login.microsoftonline.com/<tenant-id>/v2.0",
  "oidc_client_id": "<application-client-id>",
  "oidc_protected_paths": ["/"]
}

The client secret was passed through the environment:

SQLPAGE_OIDC_CLIENT_SECRET='<redacted>'

Minimal index.sql:

select 'text' as component, 'OIDC login worked' as contents;

Run shape:

RUST_LOG='sqlpage::webserver::oidc=debug,sqlpage=info,actix_web::middleware::logger=info' \
LOG_LEVEL='sqlpage::webserver::oidc=debug,sqlpage=info,sqlpage::access=info' \
SQLPAGE_OIDC_CLIENT_SECRET='<redacted>' \
./sqlpage.bin \
  --web-root /private/tmp/sqlpage-entra-repro/web \
  --config-file /private/tmp/sqlpage-entra-repro/config/sqlpage.json

Observed result with v0.42.0:

• SQLPage discovered the Entra metadata and JWKS successfully.
• SQLPage generated redirect URL: http://localhost:8080/sqlpage/oidc_callback.
• Browser request to / returned 303 to the Microsoft login flow.
• /sqlpage/oidc_callback?... was received by SQLPage.
• Token exchange to https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token returned 200.
• SQLPage redirected back to /.
• Final / returned 200.
• Page showed OIDC login worked.

Observed result with v0.43.0:

• Same config, same Entra app, same local port.
• SQLPage discovered the Entra metadata and JWKS successfully.
• SQLPage generated redirect URL: http://localhost:8080/sqlpage/oidc_callback.
• Browser request to / returned 303 to the Microsoft login flow.
• /sqlpage/oidc_callback?... was received by SQLPage.
• Token exchange to https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token returned 200.
• SQLPage redirected back to /.
• Final / returned 200.
• Page showed OIDC login worked.

We specifically did not see:

• an infinite redirect loop
• a 5-second timeout reading the token response body
• the homepage hanging after authentication
• a changed configuration parameter name requirement

Useful next diagnostics from your environment:

• Confirm whether v0.42.0 and v0.43.0 were tested at the same time with the same Entra app registration, same redirect URI, same hostname, same reverse proxy, and same browser profile.
• Try the minimal SQLite + one-line index.sql repro above. If that works but your MSSQL app hangs, the issue may be after authentication rather than in OIDC.
• Capture a browser HAR with "Preserve log" enabled. The key thing is whether the flow repeats / -> Microsoft -> /sqlpage/oidc_callback -> / -> Microsoft.
• Capture SQLPage OIDC debug logs, but send them privately if they include tokens, cookies, or authorization codes.
• Tell us the exact failing artifact: GitHub release binary, Docker image tag, platform package, or source build.
• Tell us whether SQLPage is behind Azure App Service, Application Gateway, nginx, Traefik, IIS, or another reverse proxy, and whether the public URL is at / or a sub-path.

[htnotc]

Hello,

Thanks for the quick replies.

I am using the same browsers with version 0.42 and 0.43 which are Chrome and Edge. Same Entra app registration, same redirectURL, same hostname and same reverse proxy and same browser profile.

I will reproduce my issue and send you the HAR and OIDC logs, hopefully in the next few days.

It's important to note that I am using a Docker container to host my SQLPage website (currently: lovasoa/sqlpage:v0.42.0) and the port being used is 8585. The reverse proxy that I am using is Ngrok and there is no sub-path configured.

The index sql file is only comprised of a simple greeting ('Welcome back, ' + sqlpage.user_info('name') + '!' as title) and a listing of all the available SQLPage sql files. Also, I am using a dynamic component for switching between dark mode and not dark mode.
SELECT 'dynamic' AS component,
sqlpage.run_sql('shell.sql')
AS properties;

Hope this helps narrow it a little bit more.

[htnotc]

I found the culprits!

From the moment that I used a dynamic component or sqlpage.user_info or run some queries in the homepage index file (its for showing some stats), the query to the homepage never finishes. If I just show a listing of the available SQLPage pages (text and underlying urls), I have no issue and the homepage is processed successfully.

Interesting, from the homepage with static content, if I try to open another SQLPage page (with SQL queries inside), the web request hangs as well. For some reasons, any SQL queries inside any sql files will make the browser never finished his request.

[htnotc]

This is the Ngrok error I get after a web request to a sql file fails to load:
ERR_NGROK_3004
ngrok gateway error
The server returned an invalid or incomplete HTTP response.

In the SQLPage trace, I can see these logs after waiting for a while:
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg="start flags: Flags(STARTED)" target=actix_http::h1::dispatcher
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg="start timers:" target=actix_http::h1::dispatcher
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg=" head timer is inactive" target=actix_http::h1::dispatcher
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg=" keep-alive timer is inactive" target=actix_http::h1::dispatcher
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg=" shutdown timer is inactive" target=actix_http::h1::dispatcher
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg="end timers:" target=actix_http::h1::dispatcher
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg=" head timer is inactive" target=actix_http::h1::dispatcher
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg=" keep-alive timer is inactive" target=actix_http::h1::dispatcher
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg=" shutdown timer is inactive" target=actix_http::h1::dispatcher
sqlpage | ts=2026-06-13T16:35:13.441Z level=trace msg="end flags: Flags(STARTED | READ_DISCONNECT)" target=actix_http::h1::dispatcher

[htnotc]

This is a redacted version of my "database_url": "mssql://sql_username@sql_instance_name:sql_password@sql_instance_name.database.windows.net:1433/database_name"

Did the connection string format for a Azure SQL database changed between version 0.42 and 0.43?

[lovasoa]

No, the Azure SQL connection-string format should not have changed between SQLPage 0.42 and 0.43.

Your latest findings point to something more specific: login seems to work, but the response hangs when SQLPage has to execute real SQL, sqlpage.user_info, or sqlpage.run_sql. The Ngrok error and the Actix READ_DISCONNECT logs only mean the browser/proxy eventually gave up waiting; they do not show where SQLPage was stuck before that.

Could you please run this small test in a non-production copy of your deployment? It should tell us whether the problem is the database query itself, Ngrok, OIDC, or your real page SQL.

1. Add these two temporary files:

_debug_static.sql

select 'text' as component, 'static ok' as contents;

_debug_db.sql

select 'text' as component, db_name() as contents;

2. Temporarily make only these two pages public:

"oidc_public_paths": ["/_debug_static.sql", "/_debug_db.sql"]

3. With the failing SQLPage version, test SQLPage directly from the machine/container host, without Ngrok:

curl -v --max-time 30 http://127.0.0.1:8585/_debug_static.sql
curl -v --max-time 30 http://127.0.0.1:8585/_debug_db.sql

4. Test the same two URLs through Ngrok.

5. Please send us:

• whether each of the four requests succeeds, errors, or times out
• the complete SQLPage logs from startup through those four requests, using:

RUST_LOG='sqlpage=debug,sqlpage::webserver::database=trace,sqlx::query=trace'
LOG_LEVEL="$RUST_LOG"

• the exact SQLPage Docker image tag that fails
• your redacted sqlpage.json
• your index.sql and shell.sql, with secrets/private data removed

If any of that contains tokens, cookies, connection strings, SQL contents, or user data, please send it privately to contact@ophir.dev instead of posting it publicly.

What we checked about the connection string

I checked the SQLPage and database-driver side. SQLPage 0.42.0 and 0.43.0 use the same MSSQL connection-string parser, and the URL parsing libraries are unchanged too. I also compared the MSSQL parser used by newer versions and did not find a connection-string format change.

The Azure-style username containing @ should be accepted. However, if the real password contains URL-reserved characters such as #, ?, /, or %, it still needs to be percent-encoded, or you can move it to SQLPage's separate database_password setting.

[htnotc]

I will send you the logs tomorrow but for now, in default logging mode (not trace), "_debug_db.sql" produces this output:

[it works perfectly fine in version 0.42.0 and I can see the database name but not in the latest version 0.44.1]

sqlpage | ts=2026-06-14T14:40:30.902Z level=info msg="Configuration loaded from /etc/sqlpage" target=sqlpage::app_config
sqlpage | ts=2026-06-14T14:40:31.080Z level=info msg="Not applying database migrations because '/etc/sqlpage/migrations' does not exist" target=sqlpage::webserver::database::migrations
sqlpage | ts=2026-06-14T14:40:31.972Z level=info msg="OIDC redirect URL for oidc_url: https://website_domain_url/sqlpage/oidc_callback" target=sqlpage::webserver::oidc
sqlpage | ts=2026-06-14T14:40:31.973Z level=info msg=" ✨ SQLPage v0.44.1 started successfully! ✨ View your website at: 🔗 http://localhost:8585 (also accessible from other devices using your IP address) Create your pages with SQL files in: 💻 /var/www Happy coding! 🚀" target=sqlpage::webserver::http
sqlpage | ts=2026-06-14T14:40:42.784Z level=error msg="In "_debug_db.sql": The following error occurred while executing an SQL statement: error returned from database: ODBC emitted an error calling 'SQLExecDirect': State: 42000, Native error: 0, Message: ODBC_DuckDB->PrepareStmt Catalog Error: Scalar Function with name db_name does not exist! Did you mean "dayname"? LINE 1: SELECT 'text' AS component, db_name() AS contents; ^ The SQL statement sent by SQLPage was: SELECT 'text' AS component, db_name() AS contents; _debug_db.sql: line 1" target=sqlpage::webserver::database::execute_queries code.file.path=_debug_db.sql http.request.method=GET url.path=/_debug_db.sql client.address=ip_address
sqlpage | ts=2026-06-14T14:40:42.784Z level=error msg="An error occurred before starting to send the response body: In "_debug_db.sql": The following error occurred while executing an SQL statement: error returned from database: ODBC emitted an error calling 'SQLExecDirect': State: 42000, Native error: 0, Message: ODBC_DuckDB->PrepareStmt Catalog Error: Scalar Function with name db_name does not exist! Did you mean "dayname"? LINE 1: SELECT 'text' AS component, db_name() AS contents; ^ The SQL statement sent by SQLPage was: SELECT 'text' AS component, db_name() AS contents; _debug_db.sql: line 1" target=sqlpage::webserver::error code.file.path=_debug_db.sql http.request.method=GET url.path=/_debug_db.sql client.address=ip_address
sqlpage | ts=2026-06-14T14:40:42.789Z level=error msg="500 Internal Server Error" target=sqlpage::webserver::http http.request.method=GET url.path=/_debug_db.sql client.address=ip_address
sqlpage | ts=2026-06-14T14:40:43.417Z level=info msg="OIDC redirect URL for oidc_url: https://website_domain_url/sqlpage/oidc_callback" target=sqlpage::webserver::oidc

The html output:
An error occurred
We are sorry, but an error occurred while generating this page. You should contact the site's administrator.
Please contact the administrator for more information. The error has been logged.