🚀 Feature: Add ability to create log files #231

New Issue

OVERLORD · 2025-10-07T23:58:33+03:00

OVERLORD commented

2025-10-07 23:58:33 +03:00

Originally created by @gtensolr on GitHub.

Feature description

The proposed feature if for Pocket ID to generate log files, so they could be parsed by other tools. It would be important to have the option of log level, file_location and format. This could be set on environmental variables or even within the GUI

Pitch

On several containers that are related to Authentication, they can be configured to generate log files, that can be parsed by tools such as Fail2ban and Crowdsec. Although the attack vector for Pocket ID is quite small, there's still a possibility for a malicious actor to attempt to brute force the Login Code. Even if there are no codes configured (thus no real attack vector), it's an important source of info for firewall and blocking malicious IPs.

Originally created by @gtensolr on GitHub. ### Feature description The proposed feature if for Pocket ID to generate log files, so they could be parsed by other tools. It would be important to have the option of `log level`, `file_location` and `format`. This could be set on environmental variables or even within the GUI ### Pitch On several containers that are related to Authentication, they can be configured to generate log files, that can be parsed by tools such as Fail2ban and Crowdsec. Although the attack vector for Pocket ID is quite small, there's still a possibility for a malicious actor to attempt to brute force the `Login Code`. Even if there are no codes configured (thus no real attack vector), it's an important source of info for firewall and blocking malicious IPs.

OVERLORD closed this issue

2025-10-07 23:58:34 +03:00

OVERLORD commented

2025-10-07 23:58:35 +03:00

@ItalyPaleAle commented on GitHub:

I agree that we should look into logs, and ideally implement structured logging (with log/slog which is now in the standard library).

I do not support the idea of implementing direct log-to-file. Pocket ID is meant to run as a container, and the more we can keep the app stateless, the better. The orchestrator (Docker or whatnot) can get the logs from stdout and redirect them to a file as needed, and will also take care of rotating log files, compressing them, and/or forwarding them to some other service.

However, once we do switch to structured logs, it'd be great if we could also support OTel for logs. We already have OTel for traces and metrics, and adding logs would complete the picture. That should allow forwarding logs too any receiver.

@ItalyPaleAle commented on GitHub: I agree that we should look into logs, and ideally implement structured logging (with log/slog which is now in the standard library). I do not support the idea of implementing direct log-to-file. Pocket ID is meant to run as a container, and the more we can keep the app stateless, the better. The orchestrator (Docker or whatnot) can get the logs from stdout and redirect them to a file as needed, and will also take care of rotating log files, compressing them, and/or forwarding them to some other service. However, once we do switch to structured logs, it'd be great if we could also support OTel for logs. We already have OTel for traces and metrics, and adding logs would complete the picture. That should allow forwarding logs too any receiver.

OVERLORD commented

2025-10-07 23:58:35 +03:00

@rossdargan commented on GitHub:

I've installed it on proxmox in an LXC so log-to-file for crowdsec would be really helpful.

@rossdargan commented on GitHub: I've installed it on proxmox in an LXC so log-to-file for crowdsec would be really helpful.

OVERLORD commented

2025-10-07 23:58:36 +03:00

@gtensolr commented on GitHub:

Hi @kmendell

I think that this can potentially work, but it would be a convoluted process. I would need to have an utility that can, both receive the logs from docker and export that as a log file.

What I tried and worked with success was to replace the built in Caddy with my prior nginx instance, which in turn, generate a lot of detailed “access” logs that I was able to parse.

@gtensolr commented on GitHub: Hi @kmendell I think that this can potentially work, but it would be a convoluted process. I would need to have an utility that can, both receive the logs from docker and export that as a log file. What I tried and worked with success was to replace the built in Caddy with my prior nginx instance, which in turn, generate a lot of detailed “access” logs that I was able to parse.

OVERLORD commented

2025-10-07 23:58:37 +03:00

@kmendell commented on GitHub:

You Can export the logs from docker it self using the logging section:

    logging:
      driver: "gelf"
      options:
        gelf-address: "udp://graylog.example.com:12201"
        tag: "first-logs"

This would send all of that to your log server of choice.

Would that work for your use case?

@kmendell commented on GitHub: You Can export the logs from docker it self using the logging section: ``` logging: driver: "gelf" options: gelf-address: "udp://graylog.example.com:12201" tag: "first-logs" ``` This would send all of that to your log server of choice. Would that work for your use case?

OVERLORD commented

2025-10-07 23:58:37 +03:00

@stonith404 commented on GitHub:

Like I explained in this comment brute force attacks are practically impossible due to the rate limiting.

Nevertheless, I think file-based logging makes sense. I don't have much experience with the logger of Go so I wouldn't prioritize this issue but if someone wants to create a PR, feel free :)

@stonith404 commented on GitHub: Like I explained in [this comment](https://github.com/pocket-id/pocket-id/issues/516#issuecomment-2864020900) brute force attacks are practically impossible due to the rate limiting. Nevertheless, I think file-based logging makes sense. I don't have much experience with the logger of Go so I wouldn't prioritize this issue but if someone wants to create a PR, feel free :)

OVERLORD commented

2025-10-07 23:58:38 +03:00

@ItalyPaleAle commented on GitHub:

I don't think so - it's not like docker where you have a single "app" running, but I might be wrong!

Yup, that's why I'm saying - it wouldn't be possible within a docker container since there's only 1 process.

Inside the LXC container, you probably have a process manager of sort that's running pocket-id, right? (Systemd or something else) that may allow you to pipe logs to some other file

@ItalyPaleAle commented on GitHub: > I don't think so - it's not like docker where you have a single "app" running, but I might be wrong! Yup, that's why I'm saying - it wouldn't be possible within a docker container since there's only 1 process. Inside the LXC container, you probably have a process manager of sort that's running pocket-id, right? (Systemd or something else) that may allow you to pipe logs to some other file

OVERLORD commented

2025-10-07 23:58:39 +03:00

@ItalyPaleAle commented on GitHub:

@rossdargan if you're running inside LXC, isn't there a way to redirect stdout to a file?

@ItalyPaleAle commented on GitHub: @rossdargan if you're running inside LXC, isn't there a way to redirect stdout to a file?

OVERLORD commented

2025-10-07 23:58:39 +03:00

@rossdargan commented on GitHub:

@rossdargan

I was able to get Crowdsec to parse the nginx logs for failed auths from Pocket-ID and created a scenario that can ban the IPs. If you have nginx, I can share that

I'm using pangolin but hopefully that will work. I think the biggest issue was most were 400 - but I'd love to see what you used!

@rossdargan if you're running inside LXC, isn't there a way to redirect stdout to a file?

I don't think so - it's not like docker where you have a single "app" running, but I might be wrong!

@rossdargan commented on GitHub: > [@rossdargan](https://github.com/rossdargan) > > I was able to get Crowdsec to parse the nginx logs for failed auths from Pocket-ID and created a scenario that can ban the IPs. If you have nginx, I can share that I'm using pangolin but hopefully that will work. I think the biggest issue was most were 400 - but I'd love to see what you used! > [@rossdargan](https://github.com/rossdargan) if you're running inside LXC, isn't there a way to redirect stdout to a file? I don't think so - it's not like docker where you have a single "app" running, but I might be wrong!

OVERLORD commented

2025-10-07 23:58:39 +03:00

@stonith404 commented on GitHub:

Since Pocket ID now runs in a single process it should be pretty easy to redirect stdout to a file as @ItalyPaleAle mentioned. Additionally @ItalyPaleAle has added support for sending logs to a collector like OTEL.

Because of that I'm closing this issue.

@stonith404 commented on GitHub: Since Pocket ID now runs in a single process it should be pretty easy to redirect stdout to a file as @ItalyPaleAle mentioned. Additionally @ItalyPaleAle has added support for sending logs to a collector like OTEL. Because of that I'm closing this issue.

OVERLORD commented

2025-10-07 23:58:40 +03:00

@gtensolr commented on GitHub:

@rossdargan

I was able to get Crowdsec to parse the nginx logs for failed auths from Pocket-ID and created a scenario that can ban the IPs. If you have nginx, I can share that

@gtensolr commented on GitHub: @rossdargan I was able to get Crowdsec to parse the nginx logs for failed auths from Pocket-ID and created a scenario that can ban the IPs. If you have nginx, I can share that

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-1#231