Enhancing the Visit Object for Better Request Analysis

[NadyaAncheva]

Hi, Alejandro
We’ve been working with Shlink and noticed that the current Visit object doesn’t provide enough context for deeper request analysis. Specifically, we’re seeing a number of false negatives from the CrawlerDetect framework — cases where potential security scanners are not being identified as crawlers.
To improve post‑processing and detection accuracy, we’d like to discuss enhancing the Visit object to optionally include:

• Requester/Source IP (not just derived location)
• Original HTTP Request headers (for diagnostic and trace analysis)
  These additions would allow us to perform more advanced correlation and filtering based on IP and header patterns.
  We understand the privacy implications, so we’d propose implementing this behind a feature toggle, for example:
• Option A: Expose the Remote IP (behind a “I take care of GDPR/DPA myself” flag)
• Option B: Expose diagnostic HTTP headers (which may include the Remote IP)
• Option C: Expose trace headers such as X-Amzn-Trace-Id, X-Amz-Cf-Id, or traceparent
  If this direction aligns with your vision for Shlink, we’d be happy to contribute a patch implementing these enhancements.
  Would you prefer this as a code contribution or would a donation be more appropriate?
  Looking forward to your thoughts — we’d like to start with a discussion to ensure the approach fits your roadmap.
  Best regards,
  Nadya Popova
  Riva Team

[acelaya]

So you are basically saying some bots are not properly detected as bots. I think your proposal is pretty overkill for that.

I think the solution would be to enhance that, either by a) finding a better dependency for bot detection, b) reporting this specific cases back to CrawlerDetect or c) adding extra custom logic in Shlink the can still overwrite the result from whatever dependency is used.

I would prefer a or b, as detecting boots is out of Slink's responsibilities.