feat: add getRequestFingerprint util

[nandi95]

closes #536

[codecov]

Codecov Report

Merging #548 (c0e2f6a) into main (b7aca96) will increase coverage by 0.40%.
The diff coverage is 100.00%.

❗ Current head c0e2f6a differs from pull request most recent head b7aca96. Consider uploading reports for the commit b7aca96 to get more accurate results

@@            Coverage Diff             @@
##             main     #548      +/-   ##
==========================================
+ Coverage   83.83%   84.23%   +0.40%     
==========================================
  Files          31       31              
  Lines        3563     3629      +66     
  Branches      543      550       +7     
==========================================
+ Hits         2987     3057      +70     
+ Misses        576      572       -4     

Files	Coverage Δ
src/utils/request.ts	96.19% <100.00%> (+3.30%)	⬆️

[pi0]

Thanks for working on this.

It seems a useful utility for security / rate-limiting purposes. (/cc @danielroe mentioned you if have any concerns to avoid introducing this utility as-is)

Considering this usage, i have market it as experimental for now and only enabled IP hashing by default (without trust on X-Forwarded-For).

Features (xfowarded/path/method/userAgent) can be enabled opt-in by default.

PR welcome for more improvements.

[nandi95]

This seems good to me. I don't get why have the path and method opt in. Unlike userAgent, they cannot be spoofed?

Side note, perhaps this or another utility can account for the whole request as is, including the query string, body and headers. Such a thing would be useful if someone had to de-duplicate requests (if that is even a thing) or perhaps some anonymised server side analytics.

[nandi95]

Suggested change

	const fingerprintString =
	fingerprint.filter(Boolean).join("|") ||
	Math.random().toString(36).slice(2);
	if (!fingerprint.length) {
	throw new RangeError('At least one fingerprinting factor must be enabled.')
	}
	const fingerprintString = fingerprint.filter(Boolean).join("|");

[nandi95]

I would rather have an error thrown here, warning the developer. Otherwise, they might end up with different fingerprint for the same request.
(Range error is somewhat applicable, but it can be an error too)

[pi0]

We might instead disable random behavior and return null allowing usage to handle it for custom error wdty? (usually h3 utils are errorless)

[nandi95]

That's better too than a random string. In this case, the return value should be dependent on the options' argument type. Just so the user doesn't have to assert that the fingerprint is in fact a string.

[nandi95]

shall I make this change?

[pi0]

Side note, perhaps this or another utility can account for the whole request as is, including the query string, body and headers. Such a thing would be useful if someone had to de-duplicate requests (if that is even a thing) or perhaps some anonymised server side analytics.

For an analytics usecase, uniqueness of visitors is important yes, but i guess it might need to keep path unhashed otherwise it would be useless.

Mainly enabling these is dangerous for main purpose i could assume (security) because for example someone can change identity by iterating user agent or appending a query param to the end of url.

Once we had better vision (util is still in experimental state) we might improve defaults or have an option that enables all/group of defaults

[nandi95]

Opened a new PR from a branch that isn't named main as pull bot keeps nullifying the work.
#564
I think this can be closed.