🚀 Feature: Global Access Log for Admins #338

New Issue

OVERLORD · 2025-10-07T00:11:11+03:00

OVERLORD commented

2025-10-07 00:11:11 +03:00

Originally created by @panteLx on GitHub.

Originally assigned to: @kmendell on GitHub.

Feature description

Hi,

what do you think about the idea of a global access log where admins of pocket id can see who logged in at what exact time and if the login was successful or failed.

Best wishes
panteL

Pitch

I think it would be cool to see the access data of all users as an admin, especially the failed once to check if some bots are trying to get into the accounts.

See authentik for examples. You can even see how many times the login failed, when it passes and many more things.

Originally created by @panteLx on GitHub. Originally assigned to: @kmendell on GitHub. ### Feature description Hi, what do you think about the idea of a global access log where admins of pocket id can see who logged in at what exact time and if the login was successful or failed. Best wishes panteL ### Pitch I think it would be cool to see the access data of all users as an admin, especially the failed once to check if some bots are trying to get into the accounts. See authentik for examples. You can even see how many times the login failed, when it passes and many more things.

OVERLORD added the feature label 2025-10-07 00:11:11 +03:00

OVERLORD closed this issue

2025-10-07 00:11:12 +03:00

OVERLORD commented

2025-10-07 00:11:14 +03:00

@kmendell commented on GitHub:

I had this idea awhile back, to have a Log Page in the UI to track When jobs run like ldap sync etc, though i talked my self out of it could it could add complexity or confusion to pocket-id

@kmendell commented on GitHub: I had this idea awhile back, to have a Log Page in the UI to track When jobs run like ldap sync etc, though i talked my self out of it could it could add complexity or confusion to pocket-id

OVERLORD commented

2025-10-07 00:11:14 +03:00

@panteLx commented on GitHub:

Im just talking about a simple access log like the already existing one but a global one for admins where they can see a log of all users access attempts. Not something crazy like a log for LDAP sync :D

@panteLx commented on GitHub: Im just talking about a simple access log like the already existing one but a global one for admins where they can see a log of all users access attempts. Not something crazy like a log for LDAP sync :D

OVERLORD commented

2025-10-07 00:11:14 +03:00

@stonith404 commented on GitHub:

Failed login attempts don't really make sense because it's impossible to brute force a passkey without a quantum computer.

Would it be useful to see the other events anyway as an admin?

@stonith404 commented on GitHub: Failed login attempts don't really make sense because it's impossible to brute force a passkey without a quantum computer. Would it be useful to see the other events anyway as an admin?

OVERLORD commented

2025-10-07 00:11:14 +03:00

@kmendell commented on GitHub:

I could see how this is useful, especially for a bigger org use case though i can see some drawbacks as well...

@kmendell commented on GitHub: I could see how this is useful, especially for a bigger org use case though i can see some drawbacks as well...

OVERLORD commented

2025-10-07 00:11:15 +03:00

@stonith404 commented on GitHub:

@kmendell Yeah I think this would be a bit an overkill because the logs can be viewed and organized with other tools.

@stonith404 commented on GitHub: @kmendell Yeah I think this would be a bit an overkill because the logs can be viewed and organized with other tools.

OVERLORD commented

2025-10-07 00:11:16 +03:00

@nebula-it commented on GitHub:

Failed login attempts don't really make sense because it's impossible to brute force a passkey without a quantum computer.

IMO even if one cannot brute force passkey, its good for admin to have visibility into a potential brute force attack.

@nebula-it commented on GitHub: >Failed login attempts don't really make sense because it's impossible to brute force a passkey without a quantum computer. IMO even if one cannot brute force passkey, its good for admin to have visibility into a potential brute force attack.

OVERLORD commented

2025-10-07 00:11:16 +03:00

@kmendell commented on GitHub:

This was merged in: b65e693e12 , and should be available in the next release.

@kmendell commented on GitHub: This was merged in: https://github.com/pocket-id/pocket-id/commit/b65e693e12be2e7e4cb75a74d6fd43bacb3f6a94 , and should be available in the next release.

OVERLORD commented

2025-10-07 00:11:17 +03:00

@kmendell commented on GitHub:

I think for now the scope of this feature will be just a global audit log with the existing events that already are log per user.

What makes Pocket ID unique besides passkeys is the simplicity of the UI, we wont want to (i use this term loosely) 'clutter' it up with logs and unnecessary ui elements, most of what is being asked outside of the global audit log, can be retrieved via the APi now, and i think that make be a better way of getting a lot of these "advanced" events.

@stonith404 Feel free to add anything to this or correct me if im wrong.

@kmendell commented on GitHub: I think for now the scope of this feature will be just a global audit log with the existing events that already are log per user. - What makes Pocket ID unique besides passkeys is the simplicity of the UI, we wont want to (i use this term loosely) 'clutter' it up with logs and unnecessary ui elements, most of what is being asked outside of the global audit log, can be retrieved via the APi now, and i think that make be a better way of getting a lot of these "advanced" events. @stonith404 Feel free to add anything to this or correct me if im wrong.

OVERLORD commented

2025-10-07 00:11:17 +03:00

@nikdoof commented on GitHub:

It'd be nice to have some options for the event logging as well, say output to a log file, or even just have a standardised way of DB access for the events. I can imagine that bigger orgs would like to include user modification events into their SIEM.

@nikdoof commented on GitHub: It'd be nice to have some options for the event logging as well, say output to a log file, or even just have a standardised way of DB access for the events. I can imagine that bigger orgs would like to include user modification events into their SIEM.

OVERLORD commented

2025-10-07 00:11:17 +03:00

@kmendell commented on GitHub:

It'd be nice to have some options for the event logging as well, say output to a log file, or even just have a standardised way of DB access for the events. I can imagine that bigger orgs would like to include user modification events into their SIEM.

@nikdoof For those type of events you can use the docker compose log exporter and you can export the logs to a seim like splunk, graylog etc. See below for a example of this.

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

@kmendell commented on GitHub: > It'd be nice to have some options for the event logging as well, say output to a log file, or even just have a standardised way of DB access for the events. I can imagine that bigger orgs would like to include user modification events into their SIEM. @nikdoof For those type of events you can use the docker compose log exporter and you can export the logs to a seim like splunk, graylog etc. See below for a example of this. ```yaml logging: driver: "gelf" options: gelf-address: "udp://graylog.example.com:12201" tag: "first-logs" ```

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#338