You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TLDR: This feature request describes data access and modification logging which is a legal requirement in some jurisdictions.
Is your feature request related to a problem? Please describe.
Parse Server offers data access and manipulation via its Parse Dashboard. For the dashboard to be usable in a business (or even "hobby developer") environment, Parse Server needs to comply with GDPR if it handles data of "EU users"*.
The dashboard is the main (and only?) tool of Parse Server for quick and easy manual data view and manipulation. It would be beneficial for many users if the dashboard (in connection with parse server) complied with GDPR.
Describe the solution you'd like
A mechanism that logs:
User login
Data view
Data manipulation (entry / modification)
Schema manipulation
ACL manipulation
Push sending
The easiest way would probably be to add a logging mechanism to the Parse Dashboard alone, without any modification of Parse Server, if that's possible. It should store the logs in a separate file, so these logs files can be easily dealt with according to archiving requirement of GDPR (audit-proof, etc).
Describe alternatives you've considered
Not making the dashboard GRPD compliant would render it legally unusable for aforementioned data.
Alternatives:
Data manipulation directly in the DB; that shifts the GDPR compliance requirement to the DB interface.
Create a separate app with user management and logging, essentially replicating functions of the parse dashboard.
Additional context
GDPR compliance requires the logging of data access and data modification (among many other things) for data of EU residents (regardless of citizenship) and EU citizens (regardless of residency). GDPR is enforceable since 25 May 2018.
Logging on DB level was just meant as alternative if someone decides to not use Parse Dashboard and wants to be GDPR compliant.
Without committing to a PR at this point, I would like to start a conceptual discussion about how / where to implement it. So we can estimate the effort and someone can pick it up.
Suggestion 1 - dashboard centric
parse server is initialized with parameter for log file path; can be set as environment variable
dashboard logs commands it sends to the server at a central point
dashboard calls function in parse server to log command
parse server writes log entry to a log file as set in the parse server
Suggestion 2 - server centric
We could leverage the client key and instruct parse server to log commands of selected clients. IIRC each parse client SDK has a client key property based on which the server could identify clients and determine whether to log the command.
var api = new ParseServer({
log: {
clients: [
{
key: "parseDashboard",
logging: true
},
{
key: "customAdminClient",
logging: true
}
]
}
});
We can then log direct commands like a query.find(), but also calling a cloud function that executes multiple commands with useMasterKey where we would otherwise loose track of which client triggered the commands.
This way a custom developed admin app could that calls for example cloud functions could also be logged. So when a business has a moderation app and deletes a user account that could be logged.
Because the logging would all happen server side it would be consolidated for easier audit.
Even for apps that don’t require GDPR I think this is a awesome idea. I don’t have a ton of time to help with a PR but would love to weigh in on the conceptual. I would much rather see the “server centric” solution than the parse dashboard one aswell. “In theory” those with dashboard access could potentially retrieve the master key and cercumvent the dashboard logging all together. Where as, when it’s baked into parse server there isn’t any way around the logging.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Activity
acinader commentedon Feb 24, 2019
I assume that doing this at the data level (i.e. mongo logging) would not be adequate cause we don't have the user associated with the changes.
Adding to the dashboard seems reasonable to me. Would you be willing to open a pr to get it started?
mtrezza commentedon Feb 24, 2019
Logging on DB level was just meant as alternative if someone decides to not use Parse Dashboard and wants to be GDPR compliant.
Without committing to a PR at this point, I would like to start a conceptual discussion about how / where to implement it. So we can estimate the effort and someone can pick it up.
Suggestion 1 - dashboard centric
Suggestion 2 - server centric
We could leverage the client key and instruct parse server to log commands of selected clients. IIRC each parse client SDK has a client key property based on which the server could identify clients and determine whether to log the command.
query.find(), but also calling a cloud function that executes multiple commands withuseMasterKeywhere we would otherwise loose track of which client triggered the commands.I prefer suggestion 2.
mrmarcsmith commentedon Mar 17, 2019
Even for apps that don’t require GDPR I think this is a awesome idea. I don’t have a ton of time to help with a PR but would love to weigh in on the conceptual. I would much rather see the “server centric” solution than the parse dashboard one aswell. “In theory” those with dashboard access could potentially retrieve the master key and cercumvent the dashboard logging all together. Where as, when it’s baked into parse server there isn’t any way around the logging.
stale commentedon Jul 3, 2019
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
mtrezza commentedon Jul 4, 2019
don't close, open issue
stale commentedon Aug 18, 2019
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
mtrezza commentedon Aug 19, 2019
don't close, still relevant
TomWFox commentedon Aug 19, 2019
It won’t be closed now I’ve added the ‘help wanted’ label 🙂
mtrezza commentedon Mar 10, 2020
Stumbled across Parse Auditor, which addresses this issue. Not sure yet whether it is fully GDRP compliant.
https://github.com/Blackburn-Labs/parse-auditor
mtrezza commentedon Jan 13, 2021
Related: https://github.com/netreconlab/parse-hipaa
dblythy commentedon Apr 6, 2022
Is this in progress at all?
RahulLanjewar93 commentedon Sep 25, 2023
This package overwrites the triggers, which is not feasible. So I created another package that pretty much does the same.
It's not GDPR Compliant but if someone wants to use it here's the link
https://github.com/RahulLanjewar93/parse-audit-log
Suggestions are appreciated thanks!
parse-github-assistant commentedon Oct 2, 2025
🚀 Thanks for opening this issue!