Opened 10 years ago
Last modified 2 years ago
#31737 new enhancement
Unique identifier for Heartbeat API calls
Reported by: | ojrask | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | minor | Version: | 3.6 |
Component: | General | Keywords: | has-patch needs-refresh |
Focuses: | javascript | Cc: |
Description
I chose Autosave as it is the most close component to the Heartbeat API.
Currently it seems that the Heartbeat API call made are not differentiated as Heartbeat API calls. The AJAX URL used is the global JS ajaxurl
variable and the user agent is the same as the user's browser user-agent.
This makes it difficult to parse them off general server access logs and so on.
Could it be possible to add a query variable (e.g. admin-ajax.php?heartbeat=1
) or change/append the user-agent to WordPress Heartbeat API
or something?
If a user logs in to wp-admin
and leaves the session open, Apache's access.log
files will be filled with unwanted clutter originating from the Heartbeat API requests.
With a query variable or a customized user agent server admins could redirect the Heartbeat API traffic logs to a custom log file or even /dev/null
if they wish to. This could be possible with the following server directive in Apache for instance:
# Determine user agent, set environment variable depending on it. SetEnvIfNoCase User-Agent ".*WordPress Heartbeat API.*" heartbeatrequest # Normal access log, without user-agent checked heartbeat calls. CustomLog /path/to/access.log combined env=!heartbeatrequest # Heartbeat calls go to another log file. CustomLog /path/to/heartbeat.log combined env=heartbeatrequest
I know some Heartbeat API settings can be tinkered with a plugin or a theme using hooks and globals, but I think this addition should be made into the core to keep it consistent across the board.
Attachments (1)
Change History (10)
#2
@
10 years ago
- Keywords has-patch needs-testing dev-feedback added
31737.diff
applies a string append of ?|&heartbeat=1
to the Heartbeat AJAX call URL in heartbeat.js
.
#3
@
10 years ago
- Component changed from Autosave to General
- Focuses javascript added
- Version changed from 4.1.1 to 3.6
This ticket was mentioned in Slack in #core by noisysocks. View the logs.
5 years ago
#5
@
5 years ago
- Keywords needs-refresh reporter-feedback added
Hi there @ojrask , is this feature still necessary? Asking because it's been 5 years since the last update!
If it's to go ahead, the patch needs refreshing: the file structure has since changed so these changes are no longer applying cleanly.
#6
@
2 years ago
- Keywords needs-testing dev-feedback reporter-feedback removed
- Milestone set to Awaiting Review
I found this ticket while going through those without a milestone.
It seems that Gutenberg uses the Heartbeat API as well. So I am wondering if this would still be useful. I could see how this may be useful from a high level log perspective.
I'm going to reach out to the Core Hosting group for some feedback. I think they may have some good thoughts around the usefulness of this!
This ticket was mentioned in Slack in #hosting-community by desrosj. View the logs.
2 years ago
This ticket was mentioned in Slack in #hosting-community by jadonn. View the logs.
2 years ago
#9
@
2 years ago
I think this could be useful. I can't speak for any hosting companies, but let me relate an experience I had as customer of one.
A few years ago, a company which I used for a shared hosting plan contacted me and threatened to shut my account down because they were sure my account had been hacked...because of the traffic that was being logged. A little investigation on my part and I was able to point out to them that the traffic they were seeing was simply Heartbeat API calls (i.e., I'd login to WP and leave that tab open all day :-).
I changed my behavior so that the Heartbeat API wasn't exercised as much...and the company backed off.
But, if there had been an easy way for them to verify that the traffic they were seeing in their logs was indeed the Heartbeat API...it would have saved me a few days of headache thinking my account was about to be shutdown :-)
User-Agent
header cannot be changed within$.ajax
it seems (possibly related to browser specifics or keeping things consistent). Disregard that ApacheUser-Agent
directive example.