Detect and log invalid feed token attempts
Benecaster already does this, and for most sites that is enough. Invalid token attempts are recorded in the feed request log without any code from you, and an admin notice raises the ones worth looking at — see Troubleshooting invalid token alerts. If you want to know that this is being watched, it is; you do not need this recipe for that.
What the built-in log does not do is act in the moment. This recipe is for the cases where you want something to happen as the request arrives rather than after the fact: rate-limiting repeated failures from one IP or one token prefix, or alerting on a threshold of your own rather than the one Benecaster picked.
Read the numbers before you build anything on them. On an active site most invalid-token traffic is cancelled subscribers whose podcast apps are still polling an old feed URL. That is expected, it is handled — they receive the public feed — and it is not an attack. A rate-limiter tuned as though it were will mostly punish people who used to pay you.
benecaster_token_invalid fires whenever a presented token fails validation, and hands you the token prefix (the first 8 characters — safe to log, not enough to reconstruct the token) and the show ID. If you need the full picture instead — all four outcomes, with location data — benecaster_feed_request_dispatched is the better hook.
Code
<?php
add_action( 'benecaster_token_invalid', function ( string $token_prefix, int $show_id ) {
// Log to your security/observability platform. Never log the raw
// requester IP — if you need a per-source breakdown, use
// benecaster_invalid_token_recorded instead, whose $context
// carries an already-salted ip_hash.
error_log( sprintf( 'Invalid Benecaster token attempt: prefix=%s show=%d',
$token_prefix,
$show_id
) );
}, 10, 2 );
Hooks Used
Need this built rather than just documented? See our services →