Better control for function logs

[marktani]

Issue by marktani Thursday Sep 14, 2017 at 08:27 GMT Originally opened as https://github.com/graphcool/prisma/issues/556

---

What feature are you missing?

Currently, all functions are logged, including input and output data. This might contain sensitive data. An option to disable or redact logs for a specific function could would be helpful here.

Note that function logs are only accessible to the collaborators of a project.

[marktani]

Comment by kbrandwijk Sunday Oct 29, 2017 at 03:47 GMT

---

I propose adding a logLevel key to the function definitions in graphcool.yml (verbose, info, warning, error, none)

[marktani]

Comment by lastmjs Wednesday Nov 01, 2017 at 17:47 GMT

---

It would also be nice to control the number of logs that are returned to the terminal, if your function has thousands of instances then that will be a lot of logs.

[marktani]

Comment by Jannis Monday Nov 06, 2017 at 14:02 GMT

---

I guess one question is where sensitive information can appear in the system. I'd argue that in most cases it is either part of mutations (e.g. sensitive variables such as a password passed to a mutation such as signupUser) and query results (e.g. specific model attributes being returned).

CI systems like Travis allow you to mark environment vars as private and then they substitute them with their names in logging output. Of course we're not dealing with env vars here. But still, is there some feasible way to annotate the attributes and function parameters in the GraphQL schema to mark them as private? The Graphcool service could then substitute such attributes/variables with something non-sensitive.

[marktani]

Comment by kbrandwijk Monday Nov 06, 2017 at 14:08 GMT

---

@Jannis I think it's a great idea to mark fields as sensitive in your schema, and in resolver function parameters.

type User @model {
   id: ID!
   bankAccount: String @private
}

And:

type SignInPayload {
  id: ID!
  token: String! @private
}

extend type Query {
   signIn(username: String!, password: String! @private): SignInPayload
}

Attribute could be named @private, @sensitive or whatever.

[apertureless]

Hey @marktani, any updates on this?

In my mind this is quite critical, as sensitive user data like, passwords are stored unencrypted. Which will be problematic with the GDPR coming in may. And is in general a high security issue.

Especially because a lot of people are using the email-password auth templates.

[vutran]

Seems like this need to be escalated. The @private directive seems to be an ideal solution.

[apertureless]

https://www.bleepingcomputer.com/news/security/github-accidentally-recorded-some-plaintext-passwords-in-its-internal-logs/

[omnibrain]

While I like the idea of marking certain fields as private I would still like to reduce the logging to error messages on production systems. I would even disable the super verbose logging by default for NODE_ENV=production

[traviscrist]

Couldn't prisma simply move to using debug for logging so that the user of prisma can expose prisma logs if they choose to or not via filtering. To debug prisma it would be as simple as adding DEBUG=prisma* or to remove prisma logs it could be DEBUG=-prisma assuming debug was used as require('debug')('prisma')

Its a dependency of bigger projects so using debug would just make sense and not require lots of changes on the prisma side. I don't need every query prima does logged in my production logs.