[Joly0]

I have been running this feature on my own instance since March and only now got around to filing it upstream. For this PR it was rebased onto current develop and partly reworked; the reworked version is what is tested below.

Problem

The log page and the per-app access log dialog are static. Watching what a 3rd party app does (which endpoints it hits, what gets blocked) means clicking the log again and again.

Change

• The open log refreshes every 3 s, the log list every 10 s, and the per-app access log dialog every 3 s, each with a pause toggle (icon and "Auto-refresh: 3s / off").
• Polling waits for the previous request to finish (no overlapping requests on slow logs) and pauses while the browser tab is hidden.
• Scroll position and the active tab (Access log / Endpoint usage) are kept across refreshes; getLog() takes the active tab as a parameter.
• The log list markup moved into renderLogList(), shared by pages/logs.php and the new refreshLogList ajax call, so there is one copy of it.

4 files: js/logs.js, functions/logger.php, pages/logs.php, ajax/logs.php. eslint clean.

Testing

Built from this branch, Firefox.

Check	Result
Open access.log, send 2 proxied requests	both lines appear within 3 s, no reload
Pause, send 1 request	line does not appear, status shows "off"
Resume	line appears within one cycle, selected log stays highlighted
Log list	sizes update every 10 s

[austinwbest]

I am not opposed to this at all but i would want to make it more generic. Similar to SSE logic in dockwatch that keeps the containers page updating, i would want to just create a generic SSE workflow. This allows basically anything to be fed back so there can be a logging object that passes back things and if someone has other ideas (keeping the dashboard counters updated, etc) then more objects could be passed back with the generic version.

That make sense?

Edit: Feel free to join the discord server, there is a #starrproxy channel there and we can discuss things a little faster as well. Just ping me if you do.

[Joly0]

I am not opposed to this at all but i would want to make it more generic. Similar to SSE logic in dockwatch that keeps the containers page updating, i would want to just create a generic SSE workflow. This allows basically anything to be fed back so there can be a logging object that passes back things and if someone has other ideas (keeping the dashboard counters updated, etc) then more objects could be passed back with the generic version.

That make sense?

Edit: Feel free to join the discord server, there is a #starrproxy channel there and we can discuss things a little faster as well. Just ping me if you do.

Makes sense, a generic SSE stream is the cleaner long-term approach. Happy to rework this into that: one SSE endpoint the pages subscribe to, with named event types (logs first, dashboard counters etc. later).

One thing to keep in mind: each open SSE connection holds a PHP-FPM worker for as long as it is open, and the default pm.max_children is low, so a few open tabs could starve normal requests. I'd probably cap the stream lifetime and let the browser reconnect, or raise the worker count. Any preference there?

[austinwbest]

I don't think it'll be too big of an issue with people opening that many tabs, I would bump it from 5 (I think is the default) to like 10 and just wait for it to be a problem someone reports.