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.
Also see #352.
I propose adding a logLevel key to the function definitions in graphcool.yml (verbose, info, warning, error, none)
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.
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.
@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.
This issue has been moved to graphcool/graphcool-framework.
@marktani I'm not sure the issue has actually been moved to the graphcool-framework repo! I can't find it there. 馃槙
Hey @mvaivre thanks for the heads up, I moved it now: https://github.com/graphcool/graphcool-framework/issues/463. Looks like this was an oversight on my part 馃檪
Most helpful comment
@Jannis I think it's a great idea to mark fields as sensitive in your schema, and in resolver function parameters.
And:
Attribute could be named
@private,@sensitiveor whatever.