Raise AuthorizationContextMissing before resolving about action_policy-graphql

[palkan]

then it should first check for the presence of the authorization context before even resolving

It shouldn't. We cannot check for the context before making an authorization attempt or check.

This exception is meant for preventing misconfiguration problems. If you want to use policies to prevent unauthenticated access (which, IMO, is not the best way to deal with the problem), you should check for the user presence in a pre-check (that would cause ActionPolicy::Unauthorized exception and halt the resolving process).

[kaka-ruto]

What is the best way to prevent unauthenticated access? A normal before_action in the graphql_controller?

[palkan]

A normal before_action in the graphql_controller?

If the whole graph should be protected from the unauthenticated access, then—yes, it's better to handle this at the controller level.
You can respond with a GraphQL-compatible JSON manually, for example:

before_action :require_authentication!

def require_authentication!
  return if current_user

  render json: {
    errors: [
      message: "Unauthenticated"
    ]
  }
end

[palkan]

In case we need to protect only some fields, we usually use a visibility concept. Check out this deck: https://speakerdeck.com/ssnickolay/authorization-in-the-graphql-era?slide=50

[kaka-ruto]

Thanks @palkan! These were helpful.

[kaka-ruto]

Hmm, @palkan , the before action solution works. But how will I be able to bypass the check for mutations such as login and register which do not need the user to be logged in prior?

I noticed the visibility concept only works for fetching data/fields. Wondering how to secure some/most 'endpoints' before resolving. Eg for an 'updateUser' mutation

[palkan]

I noticed the visibility concept only works for fetching data/fields

Mutation/subscriptions are also fields, so, you can use visibility for them as well.

for mutations such as login and register which do not need the user to be logged in prior?

Well, then you cannot move the authentication check to the controller level. Or, you can use a different schema/endpoint for such actions; this is also an option to consider.

[kaka-ruto]

Thanks @palkan. I'll try the different options and let you know