{"action":"created","issue":{"url":"https://api.github.com/repos/getfider/fider/issues/551","repository_url":"https://api.github.com/repos/getfider/fider","labels_url":"https://api.github.com/repos/getfider/fider/issues/551/labels{/name}","comments_url":"https://api.github.com/repos/getfider/fider/issues/551/comments","events_url":"https://api.github.com/repos/getfider/fider/issues/551/events","html_url":"https://github.com/getfider/fider/pull/551","id":366174884,"node_id":"MDExOlB1bGxSZXF1ZXN0MjE5OTE0NjYw","number":551,"title":"Add Support for Persisting Audit Events","user":{"login":"cfilby","id":2702479,"node_id":"MDQ6VXNlcjI3MDI0Nzk=","avatar_url":"https://avatars0.githubusercontent.com/u/2702479?v=4","gravatar_id":"","url":"https://api.github.com/users/cfilby","html_url":"https://github.com/cfilby","followers_url":"https://api.github.com/users/cfilby/followers","following_url":"https://api.github.com/users/cfilby/following{/other_user}","gists_url":"https://api.github.com/users/cfilby/gists{/gist_id}","starred_url":"https://api.github.com/users/cfilby/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cfilby/subscriptions","organizations_url":"https://api.github.com/users/cfilby/orgs","repos_url":"https://api.github.com/users/cfilby/repos","events_url":"https://api.github.com/users/cfilby/events{/privacy}","received_events_url":"https://api.github.com/users/cfilby/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2018-10-03T04:52:58Z","updated_at":"2018-10-06T11:59:55Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/getfider/fider/pulls/551","html_url":"https://github.com/getfider/fider/pull/551","diff_url":"https://github.com/getfider/fider/pull/551.diff","patch_url":"https://github.com/getfider/fider/pull/551.patch"},"body":"**Issue:** PR for #522.  Add basic event storage schema and functionality.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/getfider/fider/issues/comments/427568328","html_url":"https://github.com/getfider/fider/pull/551#issuecomment-427568328","issue_url":"https://api.github.com/repos/getfider/fider/issues/551","id":427568328,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNzU2ODMyOA==","user":{"login":"cfilby","id":2702479,"node_id":"MDQ6VXNlcjI3MDI0Nzk=","avatar_url":"https://avatars0.githubusercontent.com/u/2702479?v=4","gravatar_id":"","url":"https://api.github.com/users/cfilby","html_url":"https://github.com/cfilby","followers_url":"https://api.github.com/users/cfilby/followers","following_url":"https://api.github.com/users/cfilby/following{/other_user}","gists_url":"https://api.github.com/users/cfilby/gists{/gist_id}","starred_url":"https://api.github.com/users/cfilby/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cfilby/subscriptions","organizations_url":"https://api.github.com/users/cfilby/orgs","repos_url":"https://api.github.com/users/cfilby/repos","events_url":"https://api.github.com/users/cfilby/events{/privacy}","received_events_url":"https://api.github.com/users/cfilby/received_events","type":"User","site_admin":false},"created_at":"2018-10-06T11:59:55Z","updated_at":"2018-10-06T11:59:55Z","author_association":"CONTRIBUTOR","body":"Sure! I can go ahead and do that. Looking at the source code it seems like it may catch more edge cases (although it has the potential to return an error). Is the expectation that Fider will always run behind a reverse proxy? Right now it looks like the clientIP is pulled from the X-Forwarded-For header, so if you run it locally the client IP looks like it will always be null. While making that PR I could go ahead and have it fallback to the RemoteAddr property of the request if the X-Forwarded-For header is empty.\r\n\r\nDo you mostly see the events table being used to prevent system abuse, or do you also envision it as a general purpose log? If you're trying to prevent abuse then you may want to leave the ClientIP mandatory and reject the request if the ClientIP can't be parsed. If we wanted to make ClientIP optional it seems like we'd want to keep INET field if possible for the stricter validation and drop the NOT NULL clause. My guess is that I could try to create a dbModel for events that uses a NullString as the datatype to make the IP optional seeing how we're currently just passing Postgres a string with the IP anyway.\r\n\r\nI'm good with any of the approaches above though (Mandatory INET, Optional INET, Optional String), so let me know what you think and I'll go ahead and make those changes."}}
{"actor":{"display_login":"cfilby"}}