Help debugging "We are sorry... Page not found" and "request to the redirect_uri path but there's no session state found" #37891

mmguero · 2025-03-06T20:28:26Z

mmguero
Mar 6, 2025

I'm working on embedding Keycloak into a docker compose-orchestrated application and I feel like I'm almost there, but that I need to get the eyballs of someone more experienced with it than I am to go the final ten yards. Disclaimer, these last few days have been my very first foray into SSO/OpenID/Keycloak/etc.

Other disclaimer: my apologies, I know this is a lot of text. If you want to TL;DR it, you could go down the bottom section where I describe the error. I've Googled a bunch, and ChatGPT's been pretty helpful as a debugging partner but it can only take you so far.

OpenResty

I'm using OpenResty to handle routing/SSL for my application.

Prior to that I was just using vanilla NGINX but I converted to OpenResty so that I could use lua-resty-openidc to do the connection to Keycloak.
Here's my Dockerfile where I'm building OpenResty and installing zmartzone/lua-resty-openidc.

NGINX Configuration

Here is my nginx.conf. You'll notice a lot of include directives, which I use for organization and reducing duplication in the .conf file. The other reason for doing this is that based on some environment variables, the application can set up out different configurations (ie., SSL vs. non-SSL; keycloak vs. ldap vs. basic auth vs. no auth, etc.) which is handled in the container entrypoint.

Here are what I think are the relevant bits of my nginx.conf:

enabling access for some Keycloak-related environment variables used in my lua block below
lua_shared_dict options
The upstream for Keycloak (connecting to the container called "keycloak" at port "8080")
For every location that I want to be accessible only after Keycloak authentication, I include this file which contains my access_by_lua_block that makes the call to openidc authenticate.
- I patterned this after the sample configuration on the zmartzone/lua-resty-openidc GitHub.
- Parameters like redirect_uri, discovery, client_id, and client_secret come from environment variables, of which mine look like this:
  - KEYCLOAK_AUTH_URL=https://<ip address>/auth
  - KEYCLOAK_AUTH_REDIRECT_URI=/auth/redirect
  - KEYCLOAK_AUTH_REALM=master
  - KEYCLOAK_CLIENT_ID=myclient
  - KEYCLOAK_CLIENT_SECRET=xxxxxxxxxxxxxxxxxxxxxxx
As I want my application's main user interface (not Keycloak) to be accessible at the root https://<ip address>/, I want Keycloak to be accessible at /auth. To do this:
- I have an NGINX location /auth directive that does a proxy_pass to the keycloak container upstream (HTTP port 8080), also setting the relevant X- HTTP headers, and setting KC_PROXY_HEADERS=xforwardedas described here
- I'm also setting KC_HTTP_RELATIVE_PATH=/auth (equivalent to --http-relative-path /auth as described here)
- I'm setting KC_HTTP_ENABLED=true so that OpenResty talks to it internally over HTTP (since OpenResty is doing the TLS termination) as described here
- Note in my environment variables above KEYCLOAK_AUTH_URL and KEYCLOAK_AUTH_REDIRECT_URI have /auth since that's expected due to the KC_HTTP_RELATIVE_PATH setting

Keycloak configuration

My application starts up
I navigate to https://<ip address>/auth and I log into the Keycloak admin interface with the bootstrapped admin user/password
I create a new username, give it a password and assigned an admin role
I created a client and set the following:
- Access settings:
  - Root URL: https://<ip address>/
  - Home URL: https://<ip address>/
  - Valid redirect URIs (I have tried a few things for this without noticing a change)
    - *
    - /auth/redirect/ (the same value as the redirect_uri value in the openidc opts)
    - https://<ip address>/*
    - https://<ip address>/auth/redirect
  - Valid post logout redirect URIs: /auth/*
  - Web origins: I've tried both https://<ip address> and *
- Client authentication: on
- Authentication flow: Standard flow and Direct access grants
I copied the client secret and client ID, set them in the environment variables I mentioned above, then restarted NGINX so it would pick them up

"We are sorry... Page not found"

I open an incognito browser window and navigate to https://<ip address> (or https://<ip address>/readme or https://<ip address>/upload or any of the other locations that proxy to the services in my application).
I'm taken, as I should be, to the "Sign in to Keycloak" login page. In Firefox's web developer tools, I see:
- Storage
  - AUTH_SESSION_ID: "xxxxxxxxxxxxxxxxxxxxxxx..."
    - Created:"Thu, 06 Mar 2025 19:53:53 GMT"
    - Domain:"<ip address>"
    - Expires / Max-Age:"Session"
    - HostOnly:true
    - HttpOnly:true
    - Last Accessed:"Thu, 06 Mar 2025 19:53:53 GMT"
    - Path:"/auth/realms/master/"
    - SameSite:"None"
    - Secure: true
    - Size:179
  - KC_AUTH_SESSION_HASH: "xxxxxxxxxxxxxxxxxxxxxxx..."
    - Created:"Thu, 06 Mar 2025 19:53:53 GMT"
    - Domain:"<ip address>"
    - Expires / Max-Age:""Thu, 06 Mar 2025 19:54:53 GMT""
    - HostOnly:true
    - HttpOnly:false
    - Last Accessed:"Thu, 06 Mar 2025 19:53:53 GMT"
    - Path:"/auth/realms/master/"
    - SameSite:"Strict"
    - Secure: true
    - Size:65
  - KC_RESTART: "xxxxxxxxxxxxxxxxxxxxxxx..."
    - Created:"Thu, 06 Mar 2025 19:53:53 GMT"
    - Domain:"<ip address>"
    - Expires / Max-Age:"Session"
    - HostOnly:true
    - HttpOnly:true
    - Last Accessed:"Thu, 06 Mar 2025 19:53:53 GMT"
    - Path:"/auth/realms/master/"
    - SameSite:"None"
    - Secure: true
    - Size:1001
  - session: "xxxxxxxxxxxxxxxxxxxxxxx..."
    - Created:"Thu, 06 Mar 2025 19:53:52 GMT"
    - Domain:"<ip address>"
    - Expires / Max-Age:"Session"
    - HostOnly:true
    - HttpOnly:true
    - Last Accessed:"Thu, 06 Mar 2025 19:53:52 GMT"
    - Path:"/"
    - SameSite:"Lax"
    - Secure: false
    - Size:`328
- Network
  - I see the expected requests (.css files, .js, .png, etc.)
  - I also see the GET https://<ip address>/auth/realms/master/protocol/openid-connect/auth?nonce=xxx...&state=xxx...&scope=openid email profile&response_type=code&client_id=myclient&redirect_uri=https://<ip address>/auth/redirect
    - I assume that this redirect_uri value is correct, as it is what's set in the redirect_uri value in the openidc opts which comes from from my KEYCLOAK_AUTH_REDIRECT_URI
    - I don't see or know where the actual page I navigated to would be (e.g., https://<ip address>/upload or whatever) in the headers/cookies or whatever, so I don't know where that should be showing up, if anywhere
    - I could post other HTTP headers if they'd be useful
Authentication seems to be working correctly: if I put in an invalid username/password, I get the error message indicating that is the case.
I put in the correct username and password, and click "Sign In". I see:
- The Keycloak web page displays: We are sorry... Page not found
- NGINX access logs (excluding stuff like .js, .css, .woff, .png, etc. which are returning successfully)

<ip address> - - [06/Mar/2025:20:05:33 +0000] "POST /auth/realms/master/login-actions/authenticate?session_code=xxx.&execution=xxx.&client_id=myclient&tab_id=m5-xxx...&client_data=xxx... HTTP/1.1" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0"
<ip address> - - [06/Mar/2025:20:05:33 +0000] "GET /auth/redirect?state=xxx...&session_state=xxx...&iss=https%3A%2F%2F<ip address>%2Fauth%2Frealms%2Fmaster&code=xxx... HTTP/1.1" 404 2925 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0"

What's happening?

We are sorry... Page not found

This is where I'm sort of at a loss about where to go from here. My gut tells me it's something to do with some combination of the KC_HTTP_RELATIVE_PATH (/auth) and the redirect_uri (/auth/redirect) and my NGINX location /auth directive messing the actual redirect up, but that's just a wild guess.

I do sort of have a question about redirect_uri. As the documentation for lua-resty-openidc says:

The so called redirect_uri is an URI that is part of the OpenID Connect protocol. The redirect URI is registered with your OpenID Connect provider and is the URI your provider will redirect the users to after successful login. This URI then is handelled by lua-resty-openidc where it obtains tokens and performs some checks and only after that the browser is redirected to where your user wanted to go initially.

The redirect_uri is not expected to be handled by your appication code at all. It must be an URI wthat lua-resty-openidc is responsible for so it must be in a location protected by lua-resty-openidc. You configure the redirect_uri on the lua-resty-openidc side via the opts.redirect_uri parameter (which defaults to /redirect_uri). If it starts with a / then lua-resty-openidc will prepend the protocoll
and current hostname to it when sending the URI to the OpenID Connect provider (taking Forwarded and X-Forwarded-* HTTP headers into account). But you can also specify an absolute URI containing host and
protocoll yourself.

Before version 1.6.1 opts.redirect_uri_path has been the way to configure the redirect_uri without any option to take control over the protocoll and host parts.

Whenever lua-resty-openidc "sees" a local path navigated that matches the path of opts.redirect_uri (or opts.redirect_uri_path) it will intercept the request and handle it itself.

This works for most cases but sometimes the externally visible redirect_uri has a different path than the one locally visible to the server. This may happen if a reverse proxy in front of your server rewrites URIs before forwarding the requests. Therefore version 1.7.6 introduced a new option opts.local_redirect_uri_path. If it is set lua-resty-opendic will intercepts requests to this path rather than the path of opts.redirect_uri.

Because of the "the redirect_uri is not expected to be handled by your appication code at all" language there, I'm not doing anything specific in my nginx.conf for /auth/redirect handling, other than the fact that it would match the location /auth directive (since it starts with /auth/...) and thus be routed to the Keycloak container via the proxy_pass. I have seen some various nginx configuration examples online where people are handling the redirect URI in their NGINX configs with a location = /auth/redirect exact match location directive, and then for some reason do another (a different?) openidc authenticate call in there, but I don't understand that, and if/why it would be important; but from my reading of the documentation I quoted above I don't think I should be doing that, so I'm not.

If you made it this far, thanks. I know this was a lot of detail: I'm trying to be thorough so that someone who knows what they're doing has all the info they need to say, "Right there, dummy, that's your problem," for which I would be most grateful.

Answered by mmguero

Mar 6, 2025

I was able to get this working. In case anybody else is having the same problem, here are the things I did:

for the issue with the "page not found"
- I set the value for the environment variable used to populate redirect_uri in the opts send to oidc.authenticate to the URI on my app that I wanted it to redirect to (the documentation for that still confuses me)
for the "request to the redirect_uri path but there's no session state found" error
- this comment on zmartzone/lua-resty-openidc#514 suggested and zmartzone/lua-resty-openidc#533 indicated that lua-resty-session needs to be pinned at 3.10, which I have done
- I set proxy_cookie_flags * samesite=none secure;

It does seem to be wor…

View full answer

mmguero · 2025-03-06T21:57:37Z

mmguero
Mar 6, 2025
Author

A helpful person in the keycloak slack channel suggested the issue might be the value I'm giving for redirect_uri in the opts being sent to require("resty.openidc").authenticate(opts). He suggested that by setting it to /auth/redirect I am essentially redirecting keycloak back to itself (or, more accurately, a non-existent URI within keycloak itself). The documentation I quoted above for redirect_uri has really got me confused, so I can believe it if I'm doing something wrong there.

I tried replacing /auth/redirect for that setting with a valid path in my app (e.g., /readme) and am now getting a different error:

request to the redirect_uri path but there's no session state found

nginx-proxy-1  | 2025/03/06 21:56:38 [error] 114#114: *159 [lua] openidc.lua:1475: authenticate(): request to the redirect_uri path but there's no session state found, client: 10.9.0.215, server: , request: "GET /readme HTTP/1.1", host: "10.9.0.215"
nginx-proxy-1  | 2025/03/06 21:56:38 [error] 114#114: *159 [lua] access_by_lua(nginx_auth_rt.conf:1):17: Error during authentication: request to the redirect_uri path but there's no session state found, client: 10.9.0.215, server: , request: "GET /readme HTTP/1.1", host: "10.9.0.215"

So I will try to chase that down, assuming I'm a step closer now rather than a step further away (trading one error for another).

2 replies

mmguero Mar 6, 2025
Author

This new error message has led me to zmartzone/lua-resty-openidc#514 which is a thread I'm pulling on now.

mmguero Mar 6, 2025
Author

I was able to get this working. In case anybody else is having the same problem, here are the things I did:

for the issue with the "page not found"
- I set the value for the environment variable used to populate redirect_uri in the opts send to oidc.authenticate to the URI on my app that I wanted it to redirect to (the documentation for that still confuses me)
for the "request to the redirect_uri path but there's no session state found" error
- this comment on Problem with integration with keycloak zmartzone/lua-resty-openidc#514 suggested and Update documentation for configuration of lua-resty-session v4 zmartzone/lua-resty-openidc#533 indicated that lua-resty-session needs to be pinned at 3.10, which I have done
- I set proxy_cookie_flags * samesite=none secure;

It does seem to be working now! Hopefully if somebody else finds this it can help them out in the future.

Answer selected by mmguero

Navigation Menu

Repository navigation

Help debugging "We are sorry... Page not found" and "request to the redirect_uri path but there's no session state found" #37891

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Help debugging "We are sorry... Page not found" and "request to the redirect_uri path but there's no session state found" #37891

Uh oh!

mmguero Mar 6, 2025

OpenResty

NGINX Configuration

Keycloak configuration

"We are sorry... Page not found"

What's happening?

Replies: 1 comment · 2 replies

Uh oh!

mmguero Mar 6, 2025 Author

Uh oh!

mmguero Mar 6, 2025 Author

Uh oh!

mmguero Mar 6, 2025 Author

mmguero
Mar 6, 2025

Replies: 1 comment 2 replies

mmguero
Mar 6, 2025
Author

mmguero Mar 6, 2025
Author

mmguero Mar 6, 2025
Author