-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log all Login Attempts #67
Comments
I was thinking of creating a plug that we can add to the endpoints we want to listen to. However I think we also want to save the information of the responses (at least the status codes). |
@SimonLab if you are looking into this issue, |
Logging a response status might not be possible in every case to do directly inside a Phoenix application. However if the application fail before (e.g. error in a controller) the function might not be called |
@SimonLab if the request is failing in the controller we should be able to trace it in our logs. |
I've been reading the following articles:
This mostly deal with Logging can consume cpu and memory and can delay your application, for example when a complex datastructure is passed to
You can configure the level of log at runtime with
|
Working on this today as it's required by #122 ⏳ |
Logging now enabled. Updated code, schemas and tests included in #123 ✅ |
At present (pre-alpha!) we aren't logging anything. We need to log everything in the Auth app to help mitigate malicious activity.
The fields we want to log are:
email
- encrypted email address of the person the login attempt was made for. This allows us to keep track of how many attempts were made for a given account in a set time frame.person_id
- if the email exists in ourpeople
table log theperson_id
otherwise just theemail
so that we can later analyse the failed attempts. (e.g: typos)ip_address
- so we can rate limit byperson_id
andip_address
and so that we can inform people when their account has been accessed from an unrecognised IP.see: https://github.com/dwyl/hits/blob/cd9a8e15c6e598281b7bc6b037963dab6ac515f8/lib/hits_web/controllers/hit_controller.ex#L32-L33
user_agent_id
- same as in Hits, we will have auser_agents
schema where we store the full User Agent string then we reference it in the log rather than duplicating it.auth_provider
- e.g.google
,github
oremail
app_id
the app the person authenticated with relevant to Allow App Admin to see People (authenticated with their App) #122timstamps
(default in all Ecto/Phoenix schemas)This is related to our general quest to do Logging effectively in Phoenix Apps: dwyl/learn-devops#60
I think it makes sense to do the API logging table first and re-use it for this. dwyl/app#274 💭
The text was updated successfully, but these errors were encountered: