vishalanandl177 / DRF-API-Logger

An API Logger for your Django Rest Framework project.
https://github.com/vishalanandl177/DRF-API-Logger
Apache License 2.0
303 stars 57 forks source link

Added user and view fields in model and feature #90

Open rkisdp opened 7 months ago

rkisdp commented 7 months ago

Added 2 extra fields with complete flow to added the information into the database.

rkisdp commented 7 months ago

Hi @vishalanandl177, please review the changes and let me know if you find any problem.

ken-turgnate commented 7 months ago

@rkisdp any idea when this PR will merge and a new release will be out?

rkisdp commented 7 months ago

@rkisdp any idea when this PR will merge and a new release will be out?

@ken-turgnate Sorry but I'm not the maintainer of this repository, so can't do or tell you anything about this.

ken-turgnate commented 7 months ago

Apologies @rkisdp . @vishalanandl177 Any idea on when this land and get released? Thanks

rkisdp commented 5 months ago

Hi @vishalanandl177, any update on this PR? if there something you want me to change? I want to add more features in this module, please let me know.

tsantor commented 5 months ago

I'm interested in having the user too. This package is great, but it would be important to know WHO made the call if it was an authenticated user or not.

ashwanthbalakrishnan5 commented 4 months ago

@vishalanandl177 Are you still maintaining the Repo ?

vishalanandl177 commented 4 months ago

Yes @ashwanthbalakrishnan5

vishalanandl177 commented 4 months ago

I cannot merge because doing so may violate certain policies, as observed in various enterprise companies.

rkisdp commented 4 months ago

@vishalanandl177 I am very sorry. Can you please tell me what policies I am breaking in this commit? I will fix them.

vishalanandl177 commented 4 months ago

Based on my recent conversations with several enterprise companies, developers should not have access to user information. Allowing developers to use customer data for personal interests poses a risk.

stardust85 commented 1 month ago

TL; DR: let's make them optional, disabled by default.

Hi fellow users and devs, I have been employed in multiple SP500 enterprises that takes these risks seriously. In such companies segregation of duties is required for example by Sarbane Oxley Act. Segregation of duties means that if you can change code (you are a developer), you cannot read production DB. Only non-production. So it also means, that you cannot read any production data. You simply don't have access to it. You can only access non-production anonymized sample data in non-production DB. If they give production data access to regular developers, they miss the point of Segregation of Duties.

And only in special cases if it not possible to fix the bug without accessing those non-production data, temporary access to production data is allowed, with special approval.

Source: https://www.securends.com/segregation-of-duties/ (a bit commercial, but correct)

So I think storing ID of the user is perfectly OK.

However, to be on the safe side, it can be an option in settings.py, so one can it enable explicitly only if needed. Would it be the way to go?