UPDATE: This issue seems to have been addressed by upgrading to the latest codebase.

the usecase is that if our administrator needs to change some configuration settings which may impact current login users, the idea is to perhaps have a mechanism for force a relogin so the setting takes affect. I accomplish by writing a cmdline application and querying the phabricator_session table to invalidate the user's session, it's not integrated into the phabricator UI, but work good enough for now.

when i run the command:

phabricator b9f35351e9d486f7b825652ba2de0074b35cd2c5 (Aug 29 2016)
arcanist 10e5194752901959507223c01e0878e6b8312cc5 (Aug 26 2016)
phutil d6818e59c1764ede22cad56f8c5b1b527cb6a577 (Aug 26 2016)

I was thinking of adding some code to phabricator to set the phusr cookie for alternate-file-domain (aws cloudfront) when a user login as well in order for me to track user download of software packages in the file application. What is the security risk involve in doing this? Is there a better way of capturing a userid when they download a file being served from a CDN?

I also see a Packages application as well, however both Packages and Phragment seems to be prototype application and uninstalled on our running instance. Perhaps Packages is what i need to look into as a substitute to Files because it seems to be more access control for creation. Does Phragment and Packages support S3 storage backend? How would i would about installing it back since it is indicated as uninstalled?

thanks Evan, that did the trick!

we are using Apache webserver, and yes we are mangling the REMOTE_ADDRESS in preamble as recommended in the configure_preamble article section "adjusting client ips" because we are behind a load balancer.

The main reason for this was to see every month what's the usage of our company's SDK repository that was being downloaded/pull/clone from our partners to help in infrastructure. It also helps us to track which partner accounts that have downloaded to notify if a critical bug or vulnerability that been patch so they can retroactively merge our fix into their codebase. Our "public" repo acts like a simple download portal for partner to get our code that we push to, while actively development is done in a internal GIT environment. So partners would just clone our code and stuff it into their own development environment to be worked on. So having this analytic helps.