Get rid of the need for all auth rules in lambdas when calling graphql.
Just a few posts on the topic:
I believe they are completely unnecessary. If I can call a regular DQL query, it is definitely not more secure. Simple is better. Hacking the auth rules and changing them is bad coding IMHO, and erroneous work for developers. If the lambda is called from a custom mutation, that custom mutation should have it’s own auth rules. Simple.
Feature 2:
This is probably the easiest fix. Allow DQL within lambdas to accept JSON Mutation Format. You could easily update the code here.
Feature 1: Please don’t… Just because we can use dql to bypass auth rules does not mean that we want to bypass auth rules when also using graphql. I think this would also be more work than #2
Feature2: I assumed already that there was a way for the mutation to accept either json or rdf, but I hadn’t used it yet within a lambda. I 2nd this.
Feature 1: My argument is that lambdas are called from custom Mutations, Queries, and Types. All of those should have their own auth rules. The lambda field itself should be able to have its own auth rules. When graphql is called server-side, it makes no sense to require a second auth check on the graphql call. If you have some custom code with a situation that needs to check auth rules 2x, then maybe we make it optional.
Creating a new custom auth header to allow Admin access to a graphql mutation or query should not be an auth header hack.
In my mind calling graphql from on server-side should not have to require any headers, as it is being called on the admin level. That being said, the custom lambda field needs to be secure with its own auth rules.
Feature 2: Nope, but should be a simple fix.
You’re not really calling graphql, you’re calling a function that calls graphql, which not all cases need secured graphql access since you customize and call that function in your own specific way.
While I am currently affected with this,
Regarding #1 I would suggest that graphql should accept a different token from within lambdas.
I can get or generate a new auth token in the lambda, slight inconvenience, but it can be done. and then if I can pass that new token in the graphql requests, it would allow me to send admin tokens.
Also would recommend if we can allow having environment variables in the lambdas (I am going to create a new topic for it). so then I can add the admin credentials in the env, read those in the lambda, call a server or service to get a new JWT for admin and pass that to the graphql calls.
EDIT:
ok I see now that in the following post, it is already explained how to pass a new token to graphql, if that works then that is a proper solution IMO for #1