Audit: track user events

[stsewd]

This is to allow us to offer users some security logs around log in users and page views.

I realized that some events can be attached to a user, and others could also be attached to a project (so we are able to filter events per project, like page views). I'm not sure if we should keep these after the attached project is deleted, maybe we do?

Another thing is that creating these events on doc serving will trigger a lot of other resources and becomes quite noisy

So, I think it makes sense to attach this event to the analytics endpoint, but a downside is that someone can skip that easily.

This is missing tests, but wanted to confirm those points before writing them

This is another screenshot using another browser

[ericholscher]

@stsewd I think we want it attached to proxito still for auditing, but we don't want to record media queries. I think we can filter by HTML & PDF, which should be enough. I'm guessing we already have this logic somewhere in the codebase I imagine, but *.html might do the trick for the basic version. Eventually we could make the file extensions configurable perhaps.

[stsewd]

@ericholscher that did the trick! What about my other question, should we delete the logs attached to a project (page views for now) after a project is deleted? or keep them the same way when a user is deleted?

[ericholscher]

I think we want to keep everything if possible. So probably a similar approach to the user. For auditing we definitely don't want people to be able to cover their tracks by deleting something they have access to.

[stsewd]

ok, I think another step would be to have a task to clean those after some time, pageviews will generate a lot of records.

[ericholscher]

@stsewd yea -- we're only going to turn this on for specific paid plans, not everyone. Part of what they'll be paying for is storage. If it becomes super large, we could always record these in a secondary DB, but we're a long way off from that :)

[ericholscher]

This looks like a good start 👍 Excited to get the login/logout audit log, and then I think we have the basics ready to ship and test out, along with billing integration on .com

[ericholscher]

I feel like we already have this code on .com -- this is porting it right?

[stsewd]

yeah, I'm porting this piece from .com, so we have all code here.

[stsewd]

This should be ready for review now, I'm only missing writing some tests on .com.

[ericholscher]

Changes look good. Curious what our plan for rolling this out is. I'd like to figure out a way to turn it on for one of our projects first, so maybe we can do that on .com. Currently there's no way to enable it on .org -- should we add a feature flag or something simple to enable it for testing?

[stsewd]

should we add a feature flag or something simple to enable it for testing?

I was thinking that maybe we can find a way to have a mapping of some features flags to plan features, so we don't have to change our code in .org/.com or leave it as a method that only returns true/false every time we have to do a check like this, but only check for project.has_feature(Feature) and check for feature flags and the plans mapping internally.

But the real testing here is when using the auth backends on page views, log in and log out are enabled on both sites (we could also kill it on .org if we consider)

[ericholscher]

Sounds good. I think we can move forward with testing this on .com for now 👍