Double checking in the click app and in the processing scripts was
difficult. Just trust the click app and assume any request that got
a 302 response is valid.
Some advertisers set their ad's url to an intermediate tracker so
they can independently track clicks. This results in a series of
redirects like this:
reddit tracker > intermediate tracker > final destination
The ad's url is communicated to the reddit tracker through a query
parameter which is urlencoded on reddit.com and then unquoted when
being handled by the reddit tracker. This unquoting causes problems
if there is an intermediate tracker with its own query string
that needs to be urlencoded. This commit adds handling for those query
strings.
The queries are used to find the ids of PromoCampaign or Link objects
and we don't need the many (one per campaign per subreddit target per day)
PromotionWeights objects.
Ok, now I'm getting some angst in my commit messages like my
predecessors had. I understand now. It's a terrible burden. Why must
the calendar progress? Why must numbers increment? The world is
forever turning.
The future is here.
It is 2014.
Previously, the subreddit/domain and account precomputers were separate.
This merges the two and improves their portability in the process.
Because of the increased portability, the precomputer can now be added
to the install script by default.
This attribute can serve as a handy indicator that a user is a moderator
somewhere and can therefore replace the more costly modship lookup in
reddit_base.
This is intended to reduce the number of critical secrets stored in the
INI file. An initial subset of secrets is moved into the vault to test
things out.
This model will initially be used to transfer subreddit images (used in
the stylesheet) off to a new system, but is intended to be used for
per-wikipage images in the future as well.
The static files S3 bucket has been getting a lot larger recently,
between subreddit stylesheets being in there and the static file cleaner
being disabled due to a bug. This is causing the deploy process to take
upwards of 3 minutes just to determine that no files need to be uploaded
to the bucket.
As a short-term workaround, this changes the uploader to check each key
individually with an S3 HEAD request rather than listing the whole
bucket. This is slower than best case of listing the bucket, but is
significantly faster than the current condition (~25 second runtime
now).
