Infrastructure & Engineering

The "Unverified Email" Trap behind Beszel Auth Errors

Otama
4 min read
Progress 12 / 18
Table of Contents

I was trying to set up Pocket ID (OIDC) authentication for Beszel, and spectacularly fell into a rabbit hole. “The configuration should be correct, but it doesn’t work,” and “There are absolutely no logs.” It’s that feeling of despair every engineer has experienced at least once…

Today, I want to share the story of the “real culprit” I found after an hour of wasted effort, and the lessons learned from it.

The Mysterious Auth Error

It all started when I tried to integrate Pocket ID as an OIDC provider for Beszel, a lightweight server monitoring tool. I configured the Traefik Gateway and headers exactly as per the documentation, registered the Client ID/Secret, and confidently hit the login button! But…

The browser just displayed a cold, blank screen. Checking the developer tools, I only saw generic 400 Bad Request or 401 Unauthorized errors, with no specific reasons given.

“Well, the logs will surely tell me what’s wrong.” Thinking so, I checked the Pod’s standard output.

Terminal window
kubectl logs -f pod/beszel-xyz -n monitor

But… there was nothing there. Complete silence. Not even a trace of a login attempt.

An Hour of Paranoia

This was the beginning of my confusion. “Is the request not even reaching the app?” I thought, turning my suspicion toward the reverse proxy, Traefik.

  • Is the Middleware configuration wrong?
  • Are headers being stripped?
  • Is Gzip compression messing things up?

The paranoia didn’t stop there. I started suspecting my credentials, regenerating the Client ID and Secret multiple times. I even wondered, “Is it failing to link because an account already exists?” and tried deleting and recreating users…

I spent an hour investigating completely unrelated compression settings, tweaking configs here and there, holding my head in my hands asking “Why…?” In the end, the Traefik configuration, the credentials, and the accounts were all perfectly fine.

The True Culprit: “Unverified Email”

The breakthrough came when I simply decided to check the Beszel (actually PocketBase backend) admin dashboard or internal DB directly.

It turns out PocketBase has a specification (or setting) to save logs to an internal DB (_requests table, etc.) instead of standard output. Checking there, I finally found the true error message.

“Email cannot be empty”

…Huh? Empty?

The Mechanism

The cause was that the user I created in Pocket ID had not completed “Email Verification”. Since I’m self-hosting and haven’t set up a mail server, verifying the email hadn’t even crossed my mind.

  1. When Pocket ID sends user info via OIDC for a user with unverified email, it returns the status email_verified: false even if the email field has a value.
  2. On the other hand, Beszel’s backend (PocketBase) OIDC processing likely treats the email as untrusted (or invalid) when email_verified is false, and internally processes it as an empty email or rejects it via validation.
  3. As a result, PocketBase was angrily returning “There’s no email! (Strictly speaking, no valid email),” but its screams weren’t reaching standard output, only being quietly written into the internal DB.

When using OIDC authentication, you need to be careful to ensure that attribute information (especially email) is not only provided by the ID provider but is also in a valid state (Verified).

In the case of Pocket ID, there is a button in the admin panel to manually mark a user as verified. By doing this (probably requiring admin rights), I was able to forcibly change the authentication status, and the email was correctly linked.

Lesson: Don’t Trust “No Logs”

The lesson this time boils down to this:

“Just because there are no logs in the Pod’s standard output, doesn’t mean the application isn’t throwing errors.”

While “logs to standard output” is the convention for containerized apps (The Twelve-Factor App), not all apps follow it. Especially with apps that have built-in DBs or are designed with performance in mind, logs might be going to files or a DB.

You might want to scream, “What do you mean only startup logs are showing!?” but you have to swallow that frustration. When standard output is silent, checking the application-specific log details or a log viewer within the admin panel is often the best path to a solution.

I hope this record of my struggle helps someone else standing bewildered in front of a “silent container.” Good luck!

Related Posts