This release brings three changes to collector behaviour.
“Cookieless” tracking
The options to disable setting a cookie from the collector or respect “do not track” browser settings have been available for some time. However, they offer a binary on / off choice and don’t allow for fine-grained control, for example if you want to set cookies only for a subset of users. In version 2.1.0 we have added support for a new custom header SP-Anonymous: *
, and the collector will respond differently based on whether this header is present.
If the incoming request does not carry the SP-Anonymous: *
header, then the collector will continue to work in the same way as it has until now. However, if this header is present, the collector will now:
- not set a cookie
- change the value of the IP address to
unknown
before sinking an event to theraw
stream - remove
X-Forwarded-For
,X-Real-IP
andSet-Cookie
from the headers passed on to the event builder. (Remote-Address
is already being filtered out.)
No additional configuration is required for this to work. You only need to ensure that your tracker is setting the custom header appropriately.
On the tracker side, support for this feature will be added in the upcoming 2.17.0
release of the Snowplow JavaScript Tracker.
Kinesis stream no longer required to deploy collector on AWS
Older versions of the collector would crash on launch if the configured Kinesis stream did not exist. The goal was to protect against accidental data loss.
In 2.0.0
we introduced ‘surge protection’, the option to use an SQS buffer for persisting events when Kinesis is overwhelmed during traffic spikes. This works fine if you have deployed the collector with the SQS buffer option. However, in case of a prolonged Kinesis outage, you would be prevented from enabling the feature, as you won’t be able to redeploy the collector while Kinesis is down.
From this version, the collector will check on deploy whether the configured Kinesis stream and SQS queue exist but will no longer crash if they don’t. Instead, an error will be logged warning you about the issue.
Bad row when query string cannot be parsed
If trying to parse the query string of the request results in an IllegalUriException
, the collector will now log a GenericError
bad row with the offending query string.
For the full list of changes, please refer to the release notes: