starred/pocket-id-pocket-id-1
1
0
Fork 0
mirror of https://github.com/pocket-id/pocket-id.git synced 2025-12-09 14:53:00 +03:00
Code Issues 122 Packages Projects Releases 10 Wiki Activity

🐛 Bug Report: Logo and background image is not visible after upgrading to 1.0.0 #192

New Issue
Closed
opened 2025-10-07 23:57:04 +03:00 by OVERLORD · 8 comments
OVERLORD commented 2025-10-07 23:57:04 +03:00
Owner
Copy Link

Originally created by @gepbird on GitHub.

Reproduction steps

  1. Download this database that went through some Pocket ID version updates
  2. Start Pocket ID with UI_CONFIG_DISABLED=1 environment variable
  3. Visit http://localhost:1411/login in a browser and observe the logo and background image not loading

Expected behavior

The logo and background image loads.

Actual Behavior

The logo and background image falls back to it's alt text:

Image

Version and Environment

I started noticing this from version 1.0.0, our database was created ~3 months ago.

Note that the data dump which is attached is heavily stripped to protect privacy and hopefully make debugging simpler (if needed I may share more data via email), the only relevant information in that is some empty logo and background image fields:

Image

I assume these should've been deleted from the database with a previous migration, but wasn't. There's also a chance of me making a mistake and starting an older version after the database was upgraded to a newer version, but whenever I noticed errors from this, I immediately rolled back.

(When starting Pocket ID 1.0.0 with the attached data dumps, uploads/application-images with the logo, background and other images are automatically created.)

Log Output

[user@nixos:~]$ UI_CONFIG_DISABLED=1 /nix/store/383ag5qk1r1kl5g45y5jrm348w6kw1ip-pocket-id-1.0.0/bin/pocket-id
2025/05/31 09:26:41 MAXMIND_LICENSE_KEY environment variable is empty. The GeoLite2 City database won't be updated.
2025/05/31 09:26:41 Starting job scheduler
2025/05/31 09:26:41 Server listening on 0.0.0.0:1411
[GIN] 2025/05/31 - 09:26:45 | 200 |    5.030639ms |       127.0.0.1 | GET      "/login"
[GIN] 2025/05/31 - 09:26:45 | 200 |    5.060951ms |       127.0.0.1 | GET      "/login"
[GIN] 2025/05/31 - 09:26:45 | 401 |     116.152µs |       127.0.0.1 | GET      "/api/users/me"
Error #01: You are not signed in
[GIN] 2025/05/31 - 09:26:45 | 401 |     150.828µs |       127.0.0.1 | GET      "/api/users/me"
Error #01: You are not signed in
[GIN] 2025/05/31 - 09:26:45 | 200 |      84.048µs |       127.0.0.1 | GET      "/api/application-configuration"
[GIN] 2025/05/31 - 09:26:45 | 200 |     112.781µs |       127.0.0.1 | GET      "/api/application-configuration"
[GIN] 2025/05/31 - 09:26:45 | 404 |     213.909µs |       127.0.0.1 | GET      "/api/application-configuration/background-image"
[GIN] 2025/05/31 - 09:26:45 | 404 |     318.602µs |       127.0.0.1 | GET      "/api/application-configuration/background-image"
[GIN] 2025/05/31 - 09:26:45 | 404 |      37.099µs |       127.0.0.1 | GET      "/api/application-configuration/logo?light=true"
[GIN] 2025/05/31 - 09:26:45 | 404 |     285.884µs |       127.0.0.1 | GET      "/api/application-configuration/logo?light=true"
[GIN] 2025/05/31 - 09:26:46 | 200 |    3.146247ms |       127.0.0.1 | GET      "/_app/immutable/nodes/9.CgYX03vl.js"
[GIN] 2025/05/31 - 09:26:46 | 200 |    3.330558ms |       127.0.0.1 | GET      "/_app/immutable/nodes/9.CgYX03vl.js"
[GIN] 2025/05/31 - 09:26:46 | 401 |     180.945µs |       127.0.0.1 | GET      "/api/users/me"
Error #01: You are not signed in
[GIN] 2025/05/31 - 09:26:46 | 401 |     427.025µs |       127.0.0.1 | GET      "/api/users/me"
Error #01: You are not signed in
[GIN] 2025/05/31 - 09:26:46 | 200 |     115.367µs |       127.0.0.1 | GET      "/api/application-configuration"
[GIN] 2025/05/31 - 09:26:46 | 200 |     171.427µs |       127.0.0.1 | GET      "/api/application-configuration"
^C2025/05/31 09:26:47 Received interrupt signal. Shutting down…
2025/05/31 09:26:47 Job scheduler shut down
Originally created by @gepbird on GitHub. ### Reproduction steps 1. Download [this database](https://github.com/user-attachments/files/20532836/data.zip) that went through some Pocket ID version updates 2. Start Pocket ID with `UI_CONFIG_DISABLED=1` environment variable 3. Visit http://localhost:1411/login in a browser and observe the logo and background image not loading ### Expected behavior The logo and background image loads. ### Actual Behavior The logo and background image falls back to it's alt text: ![Image](https://github.com/user-attachments/assets/9aba259b-650a-435c-a576-14173304a42d) ### Version and Environment I started noticing this from version 1.0.0, our database was created ~3 months ago. Note that the data dump which is attached is heavily stripped to protect privacy and hopefully make debugging simpler (if needed I may share more data via email), the only relevant information in that is some empty logo and background image fields: ![Image](https://github.com/user-attachments/assets/3587d75a-6541-405a-9598-a638d46817a1) I assume these should've been deleted from the database with a previous migration, but wasn't. There's also a chance of me making a mistake and starting an older version after the database was upgraded to a newer version, but whenever I noticed errors from this, I immediately rolled back. (When starting Pocket ID 1.0.0 with the attached data dumps, uploads/application-images with the logo, background and other images are automatically created.) ### Log Output ```console [user@nixos:~]$ UI_CONFIG_DISABLED=1 /nix/store/383ag5qk1r1kl5g45y5jrm348w6kw1ip-pocket-id-1.0.0/bin/pocket-id 2025/05/31 09:26:41 MAXMIND_LICENSE_KEY environment variable is empty. The GeoLite2 City database won't be updated. 2025/05/31 09:26:41 Starting job scheduler 2025/05/31 09:26:41 Server listening on 0.0.0.0:1411 [GIN] 2025/05/31 - 09:26:45 | 200 | 5.030639ms | 127.0.0.1 | GET "/login" [GIN] 2025/05/31 - 09:26:45 | 200 | 5.060951ms | 127.0.0.1 | GET "/login" [GIN] 2025/05/31 - 09:26:45 | 401 | 116.152µs | 127.0.0.1 | GET "/api/users/me" Error #01: You are not signed in [GIN] 2025/05/31 - 09:26:45 | 401 | 150.828µs | 127.0.0.1 | GET "/api/users/me" Error #01: You are not signed in [GIN] 2025/05/31 - 09:26:45 | 200 | 84.048µs | 127.0.0.1 | GET "/api/application-configuration" [GIN] 2025/05/31 - 09:26:45 | 200 | 112.781µs | 127.0.0.1 | GET "/api/application-configuration" [GIN] 2025/05/31 - 09:26:45 | 404 | 213.909µs | 127.0.0.1 | GET "/api/application-configuration/background-image" [GIN] 2025/05/31 - 09:26:45 | 404 | 318.602µs | 127.0.0.1 | GET "/api/application-configuration/background-image" [GIN] 2025/05/31 - 09:26:45 | 404 | 37.099µs | 127.0.0.1 | GET "/api/application-configuration/logo?light=true" [GIN] 2025/05/31 - 09:26:45 | 404 | 285.884µs | 127.0.0.1 | GET "/api/application-configuration/logo?light=true" [GIN] 2025/05/31 - 09:26:46 | 200 | 3.146247ms | 127.0.0.1 | GET "/_app/immutable/nodes/9.CgYX03vl.js" [GIN] 2025/05/31 - 09:26:46 | 200 | 3.330558ms | 127.0.0.1 | GET "/_app/immutable/nodes/9.CgYX03vl.js" [GIN] 2025/05/31 - 09:26:46 | 401 | 180.945µs | 127.0.0.1 | GET "/api/users/me" Error #01: You are not signed in [GIN] 2025/05/31 - 09:26:46 | 401 | 427.025µs | 127.0.0.1 | GET "/api/users/me" Error #01: You are not signed in [GIN] 2025/05/31 - 09:26:46 | 200 | 115.367µs | 127.0.0.1 | GET "/api/application-configuration" [GIN] 2025/05/31 - 09:26:46 | 200 | 171.427µs | 127.0.0.1 | GET "/api/application-configuration" ^C2025/05/31 09:26:47 Received interrupt signal. Shutting down… 2025/05/31 09:26:47 Job scheduler shut down ```
OVERLORD added the bug label 2025-10-07 23:57:04 +03:00
OVERLORD commented 2025-10-07 23:57:07 +03:00
Author
Owner
Copy Link

@EweSparky commented on GitHub:

I have the same issue with v1.1.0 using Docker. I haven't modified the database or used custom images. I can see the files exist:

me@server:/srv/docker/pocket-id$ sudo docker exec -it pocket-id tree /app
/app
├── data
│   ├── GeoLite2-City.mmdb
│   ├── keys
│   │   ├── jwt_private_key.json
│   │   └── jwt_public_key.pem
│   ├── pocket-id.db
│   ├── pocket-id.db-shm
│   ├── pocket-id.db-wal
│   └── uploads
│       ├── application-images
│       │   ├── background.jpg
│       │   ├── favicon.ico
│       │   ├── logo.svg
│       │   ├── logoDark.svg
│       │   └── logoLight.svg
│       ├── oidc-client-images
│       │   ├── 00b63aba-f1c3-4779-858a-91ba5918d9e5.png
│       │   ├── 12911e9e-15c5-4dd4-8de6-b68bb3fa77ad.svg
│       │   ├── 5d0248da-f10d-4b73-895e-a9346fcd8f30.png
│       │   ├── 91116cd2-164e-4fca-9673-b6f29caf84fe.svg
│       │   └── b0938249-18a7-4a6b-a29a-8a3d61df2da0.png
│       └── profile-pictures
│           ├── 4f57f26c-6afa-4f96-9db0-93ba9e192451.png
│           └── defaults
│               └── PA.png
├── docker
│   └── entrypoint.sh
└── pocket-id

8 directories, 20 files
me@server:/srv/docker/pocket-id$
@EweSparky commented on GitHub: I have the same issue with v1.1.0 using Docker. I haven't modified the database or used custom images. I can see the files exist: ```text me@server:/srv/docker/pocket-id$ sudo docker exec -it pocket-id tree /app /app ├── data │ ├── GeoLite2-City.mmdb │ ├── keys │ │ ├── jwt_private_key.json │ │ └── jwt_public_key.pem │ ├── pocket-id.db │ ├── pocket-id.db-shm │ ├── pocket-id.db-wal │ └── uploads │ ├── application-images │ │ ├── background.jpg │ │ ├── favicon.ico │ │ ├── logo.svg │ │ ├── logoDark.svg │ │ └── logoLight.svg │ ├── oidc-client-images │ │ ├── 00b63aba-f1c3-4779-858a-91ba5918d9e5.png │ │ ├── 12911e9e-15c5-4dd4-8de6-b68bb3fa77ad.svg │ │ ├── 5d0248da-f10d-4b73-895e-a9346fcd8f30.png │ │ ├── 91116cd2-164e-4fca-9673-b6f29caf84fe.svg │ │ └── b0938249-18a7-4a6b-a29a-8a3d61df2da0.png │ └── profile-pictures │ ├── 4f57f26c-6afa-4f96-9db0-93ba9e192451.png │ └── defaults │ └── PA.png ├── docker │ └── entrypoint.sh └── pocket-id 8 directories, 20 files me@server:/srv/docker/pocket-id$ ```
OVERLORD commented 2025-10-07 23:57:08 +03:00
Author
Owner
Copy Link

@gepbird commented on GitHub:

I have no clue how these three values in the database can be empty. Are you sure that you didn't somehow manipulate the database manually? Is there a possibility that the NixOS package tampers with the database?

I just found our oldest backup from 2025-02-28, it also has empty values (and some more columns).

Image

In that time there was no NixOS module or package for Pocket ID, so we used it with docker.

I'm not sure how to figure out which version of Pocket ID we were using, this was schema_migrations version: 20250210152631

We didn't modify the database manually.

Additionally, did you upload custom images in the past?

Yes, we uploaded OIDC client images and a profile picture (this is from the oldest backup)

├── data
│   ├── GeoLite2-City.mmdb
│   ├── keys
│   │   ├── jwt_private_key.pem
│   │   └── jwt_public_key.pem
│   ├── pocket-id.db
│   └── uploads
│       ├── application-images
│       │   ├── background.jpg
│       │   ├── favicon.ico
│       │   ├── logoDark.svg
│       │   ├── logoLight.svg
│       │   └── logo.svg
│       ├── oidc-client-images
│       │   ├── 238bb7b6-1790-4646-b495-62fa6f2922dc.png
│       │   ├── 2ce7f03b-ba5a-40c1-9e35-35f73d676832.png
│       │   ├── 65ed3eb3-f7d4-4dc4-be74-5dea41d5f361.png
│       │   ├── 97161c7d-8596-4e2a-933a-2133e9342d04.png
│       │   ├── a5de807e-cc7c-42ff-9c60-da99247ad2ce.png
│       │   ├── ba57d59a-1b3b-4cb6-b0d2-c8a4a42788f5.png
│       │   └── fc8ceb40-6cee-4544-ba45-a091d5e227d8.png
│       └── profile-pictures
│           └── 907e225f-8605-4cf5-9dbb-86663078058a.png
└── docker-compose.yml

As a workaround you can just delete backgroundImageType, logoLightImageType and logoDarkImageType from the database.

Yes that works well, I mainly want to find out why this has happened and make sure it won't affect others. (As a maintainer of the NixOS module and package for Pocket ID I feel like we should understand issues like this, but at this point I'm starting to doubt other people will ever run into this)

Edit: note that on 0.53.0 images work well website even though the background and logo image types have empty values.

Edit 2: our 3rd oldest backup (2025-04-27) is a month younger than our 2nd oldest (2025-03-31)

In that time there was probably multiple Pocket ID version bumps. Looks like some migration was applied that deleted the default value and other columns (or maybe we started from a new database which did not create those columns at all?), it looks like this, similarly to what's in today's database:

Image

If this was a migration, maybe it should've set the value to the default value before deleting default value?

From the 2nd oldest backup we replaced the Docker container with a Nix package (that builds the frontend and backend from source) and NixOS module (that mainly starts a systemd service for the frontend and backend).

@gepbird commented on GitHub: > I have no clue how these three values in the database can be empty. Are you sure that you didn't somehow manipulate the database manually? Is there a possibility that the NixOS package tampers with the database? I just found our oldest backup from 2025-02-28, it also has empty values (and some more columns). ![Image](https://github.com/user-attachments/assets/12fb807c-9f26-4fc5-9d88-629f6ba83109) In that time there was no NixOS module or package for Pocket ID, so we used it with docker. I'm not sure how to figure out which version of Pocket ID we were using, this was schema_migrations version: `20250210152631` We didn't modify the database manually. > Additionally, did you upload custom images in the past? Yes, we uploaded OIDC client images and a profile picture (this is from the oldest backup) ```console ├── data │   ├── GeoLite2-City.mmdb │   ├── keys │   │   ├── jwt_private_key.pem │   │   └── jwt_public_key.pem │   ├── pocket-id.db │   └── uploads │   ├── application-images │   │   ├── background.jpg │   │   ├── favicon.ico │   │   ├── logoDark.svg │   │   ├── logoLight.svg │   │   └── logo.svg │   ├── oidc-client-images │   │   ├── 238bb7b6-1790-4646-b495-62fa6f2922dc.png │   │   ├── 2ce7f03b-ba5a-40c1-9e35-35f73d676832.png │   │   ├── 65ed3eb3-f7d4-4dc4-be74-5dea41d5f361.png │   │   ├── 97161c7d-8596-4e2a-933a-2133e9342d04.png │   │   ├── a5de807e-cc7c-42ff-9c60-da99247ad2ce.png │   │   ├── ba57d59a-1b3b-4cb6-b0d2-c8a4a42788f5.png │   │   └── fc8ceb40-6cee-4544-ba45-a091d5e227d8.png │   └── profile-pictures │   └── 907e225f-8605-4cf5-9dbb-86663078058a.png └── docker-compose.yml ``` > As a workaround you can just delete backgroundImageType, logoLightImageType and logoDarkImageType from the database. Yes that works well, I mainly want to find out *why* this has happened and make sure it won't affect others. (As a maintainer of the NixOS module and package for Pocket ID I feel like we should understand issues like this, but at this point I'm starting to doubt other people will ever run into this) Edit: note that on 0.53.0 images work well website even though the background and logo image types have empty values. Edit 2: our 3rd oldest backup (2025-04-27) is a month younger than our 2nd oldest (2025-03-31) In that time there was probably multiple Pocket ID version bumps. Looks like some migration was applied that deleted the default value and other columns (or maybe we started from a new database which did not create those columns at all?), it looks like this, similarly to what's in today's database: ![Image](https://github.com/user-attachments/assets/f1416b61-7680-4dad-9ee7-cc760a4d42a2) If this was a migration, maybe it should've set the value to the default value before deleting default value? From the 2nd oldest backup we replaced the Docker container with a Nix package (that builds the frontend and backend from source) and NixOS module (that mainly starts a systemd service for the frontend and backend).
OVERLORD commented 2025-10-07 23:57:08 +03:00
Author
Owner
Copy Link

@stonith404 commented on GitHub:

The reason why it has worked before v1.0.0 is probably because Pocket ID has ignored backgroundImageType, logoLightImageType and logoDarkImageType if UI_CONFIG_DISABLED was set to true. This was a bug and fixed in bf710aec56.

We never had an SQL migration that changes values in the app_config_variables table because of that I don't think that is was a migration. In the past we handled the configuration variables differently in the code though. My guess is that we had a bug in our code in a previous version and this bug set the 3 config variables to an empty string. Since you set UI_CONFIG_DISABLED to true you've never noticed that the values were empty because the values were ignored before v1.0.0.

@EweSparky @gepbird can you confirm that the issue is fixed if you remove backgroundImageType, logoLightImageType and logoDarkImageType from the app_config_variables table? Alternatively the issue should also be fixed if you upload the images again in the UI.

@stonith404 commented on GitHub: The reason why it has worked before `v1.0.0` is probably because Pocket ID has ignored `backgroundImageType`, `logoLightImageType` and `logoDarkImageType` if `UI_CONFIG_DISABLED` was set to `true`. This was a bug and fixed in bf710aec5625c9dcb43c83d920318a036a135bae. We never had an SQL migration that changes values in the `app_config_variables` table because of that I don't think that is was a migration. In the past we handled the configuration variables differently in the code though. My guess is that we had a bug in our code in a previous version and this bug set the 3 config variables to an empty string. Since you set `UI_CONFIG_DISABLED ` to `true` you've never noticed that the values were empty because the values were ignored before `v1.0.0`. @EweSparky @gepbird can you confirm that the issue is fixed if you remove `backgroundImageType`, `logoLightImageType` and `logoDarkImageType` from the `app_config_variables` table? Alternatively the issue should also be fixed if you upload the images again in the UI.
OVERLORD commented 2025-10-07 23:57:09 +03:00
Author
Owner
Copy Link

@gepbird commented on GitHub:

Since you set UI_CONFIG_DISABLED to true you've never noticed that the values were empty because the values were ignored before v1.0.0.

I'm probably misunderstanding, but this implies that not setting UI_CONFIG_DISABLED=1 (or setting UI_CONFIG_DISABLED=0) should make me notice that the values are empty, therefore make image loading fail. However without disabling the UI config, images work well and this bug is not reproducible.

can you confirm that the issue is fixed if you remove backgroundImageType, logoLightImageType and logoDarkImageType from the app_config_variables table?

Yes, that works on my minimal repro and on our production server. This is Pocket ID 1.1.0 with our ~3 months old data after removing those 3 fields:

Image

@gepbird commented on GitHub: > Since you set UI_CONFIG_DISABLED to true you've never noticed that the values were empty because the values were ignored before v1.0.0. I'm probably misunderstanding, but this implies that not setting `UI_CONFIG_DISABLED=1` (or setting `UI_CONFIG_DISABLED=0`) should make me notice that the values are empty, therefore make image loading fail. However without disabling the UI config, images work well and this bug is not reproducible. > can you confirm that the issue is fixed if you remove backgroundImageType, logoLightImageType and logoDarkImageType from the app_config_variables table? Yes, that works on my minimal repro and on our production server. This is Pocket ID 1.1.0 with our ~3 months old data after removing those 3 fields: ![Image](https://github.com/user-attachments/assets/bce11e96-cd4c-408b-ad50-79bf57eaba20)
OVERLORD commented 2025-10-07 23:57:09 +03:00
Author
Owner
Copy Link

@stonith404 commented on GitHub:

Thanks for your detailed bug report, this really helps to debug things faster.

I have no clue how these three values in the database can be empty. Are you sure that you didn't somehow manipulate the database manually? Is there a possibility that the NixOS package tampers with the database?

Additionally, did you upload custom images in the past?

As a workaround you can just delete backgroundImageType, logoLightImageType and logoDarkImageType from the database.

@stonith404 commented on GitHub: Thanks for your detailed bug report, this really helps to debug things faster. I have no clue how these three values in the database can be empty. Are you sure that you didn't somehow manipulate the database manually? Is there a possibility that the NixOS package tampers with the database? Additionally, did you upload custom images in the past? As a workaround you can just delete `backgroundImageType`, `logoLightImageType` and `logoDarkImageType` from the database.
OVERLORD commented 2025-10-07 23:57:10 +03:00
Author
Owner
Copy Link

@stonith404 commented on GitHub:

@gepbird I've identified and resolved the issue. Your hint about it working without UI_CONFIG_DISABLED=true really helped.

The problem was that the configuration loading logic was inconsistent between database and environment variable sources:

  • When loading from the database, empty string values fall back to default values
  • When loading from environment variables, this fallback logic was missing

I've added a migration in decf8ec70b that removes all configuration variables with empty values from the database. This will be included in the next release.

Thanks for the detailed reproduction steps, they made debugging much easier.

@stonith404 commented on GitHub: @gepbird I've identified and resolved the issue. Your hint about it working without `UI_CONFIG_DISABLED=true` really helped. The problem was that the configuration loading logic was inconsistent between database and environment variable sources: - When loading from the database, empty string values fall back to default values - When loading from environment variables, this fallback logic was missing I've added a migration in decf8ec70b5f6a69fe201d6e4ad60ee62e374ad0 that removes all configuration variables with empty values from the database. This will be included in the next release. Thanks for the detailed reproduction steps, they made debugging much easier.
OVERLORD commented 2025-10-07 23:57:10 +03:00
Author
Owner
Copy Link

@EweSparky commented on GitHub:

@stonith404 changing UI_CONFIG_DISABLED from true to false and restarting the container allowed the images to load. Changing it back to true caused them to break.

@EweSparky commented on GitHub: @stonith404 changing `UI_CONFIG_DISABLED` from `true` to `false` and restarting the container allowed the images to load. Changing it back to `true` caused them to break.
OVERLORD commented 2025-10-07 23:57:11 +03:00
Author
Owner
Copy Link

@stonith404 commented on GitHub:

This should be fixed in v1.2.0. Let me know if the issue still occurs.

@stonith404 commented on GitHub: This should be fixed in `v1.2.0`. Let me know if the issue still occurs.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
breaking
bug
documentation
feature
needs more upvotes
open to pull requests
pull-request
Mirrored from GitHub Pull Request
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-1#192
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?