I was thinking about some kind of sanitization here, but I don't think this is necessary. If a user receives a malicious link and clicks it, we don't have to be involved - the damage is already done. Also, the store url can be typed directly by the user, so it doesn't mean that we're redirecting to it.

My testing indicates that we can't put any value into the referrer field - it gets replaced by utm_source=google-play&utm_medium=organic. We can set some specific parts of referrer value https://developers.google.com/analytics/devguides/collection/android/v4/campaigns?hl=pl#campaign-params from which source looks the most relevant. So the value we put here is url-encoded utm_source=invite/${secret}

Should we call urlencode(secret)?

1. When :secret contains something that isn't already urlencoded, a different endpoint on keyserver will be accessed. E.g. /invite/123/abc doesn't match /invite/:secret - instead * route is matched.
2. When :secret is already url encoded we probably should encode it. E.g. /invite/123%2Fabc makes secret equal to 123/abc and breaks the store link. But even if we encode it, it might break the referrer value, e.g. if the secret would be decoded to aaa&something=value. I have to check how we can avoid this issue.

I think the solution might be to limit the possible set of secret characters to just alphanumeric. If we avoid % char, the secret should be in a state where decoding it doesn't change it. If this endpoint is called with secret containing special chars, we should avoid passing it as a referrer.

This function keeps growing - in one of the next diffs I'm going to extract it to a separate place.