Validation rules and Policies errors after update to v7 about server HOT 11 CLOSED

If you do not use ASP.NET Core Authentication / Authorization, then you may wish to continue to use the updated authorization rule provided in the authorization repo. You will need to make at least one change: within your GraphQLMiddleware.cs, you will need to add options.User = context.User; or otherwise set the User property to be the ClaimsPrincipal instance to be used by the authentication policies.

from server.

AddGraphQL is preferred over manual registration of services within the DI container for three reasons:

1. Easier configuration of GraphQL.NET. You can get started with just this:

services.AddGraphQL(b => b
    .AddSchema<MySchema>()
    .AddSystemTextJson());

Intellisense will provide assistance with all available configuration methods available to you, which lessens the need to rely on documentation to properly configure GraphQL.NET. (However, documentation is available here.)

When new features are released, such as Automatic Persisted Queries, just call the appropriate builder method, such as .AddAutomaticPersistedQueries(). Without the builder methods, adding support for Automatic Persisted Queries involves this (assuming no special configuration):

services.AddSingleton<IConfigureExecution, AutomaticPersistedQueriesExecution>();

2. Better able to handle changes to the underlying GraphQL.NET infrastructure

For example, in GraphQL.NET v8 we may introduce direct support for OpenTelemetry logging. This change may require another service to be injected into DocumentExecuter. Using the AddGraphQL builder methods, a default implementation of the required dependency would be installed without any modification to user code.

3. Easier to add third-party or user-created features to GraphQL.NET

For example, you could write a logging feature, package it into a private NuGet package, and expose .AddMyCustomLogging() as an extension method on the builder interface.

from server.

The HTTP middleware provided in the Server repo (the UseGraphQL method) has advantages over custom middleware as follows:

1. Reads queries from the query string, application/json POST, application/graphql POST, and form data post. (configurable)
2. Can read submissions in any character encoding supported by the OS.
3. Can read batch queries (configurable).
4. Supports websocket connections (configurable)
5. Supports reading and writing 'extensions' property
6. Can restrict endpoint access based on an authorization rule or policy (configurable)
7. Responds with currently suggested content type (configurable)
8. Honors Accept HTTP header if the requested content type is recognized and supported
9. Response is serialized directly to the response stream
10. Response status code for error responses is 400 (configurable)
11. Properly rejects mutation requests over GET connections, as required by GraphQL HTTP spec
12. Supports multiple schemas (across multiple endpoints)
13. Easy to install, with typically only a single line of code, such as app.UseGraphQL();
14. Can be installed as middleware, as a routing endpoint, a MVC ActionResult, or Azure Function
15. Upgrades to the GraphQL.NET infrastructure, such as the added ExecutionOptions.User property, are handled with in the middleware automatically, so less changes during version upgrades.
16. All features are supported with either the ASP.NET Core 2.1 or ASP.NET Core 3.1+ frameworks

Wish list, but not yet developed: rate limiting via IP address, user, and query complexity.

from server.

GraphQL.Authorization that it was basically obsolete

It was not. See the latest 3 PRs https://github.com/graphql-dotnet/authorization/pulls?q=is%3Apr+is%3Aclosed

We just forgot to publish v7.

from server.

The authorization repo was updated to have 7.0 compatibility but was never released. We can probably do so promptly. Even so, it is missing some features that the authorization rule built into GraphQL.NET Server 7.0 provides. The one in this repo is tailored more specifically for ASP.NET Core and should be easier to use if you plan to base your authentication policies around ASP.NET Core Authentication.

While you may continue to use your existing dependency-injection configuration and setup, you may wish to upgrade your entire 'Startup.cs' file to use the builder methods provided by .AddGraphQL(). Regardless, for the Server authentication rule to be useful, you will need to add authorization policies using ASP.NET Core's builder methods.

There are two samples that should present the currently-suggested method of configuring your application with ASP.NET Core:

Authorization sample

See: https://github.com/graphql-dotnet/server/blob/master/samples/Samples.Authorization/Program.cs

Lines 15-26 demonstrate a simple ASP.NET Core Identity framework; this is likely different for your configuration.

Line 27 is where authorization policies are configured. You will need to replace the AddPolicy calls in your Startup.cs file with ASP.NET Core Authorization policy configuration calls. See this link for more information.

Lines 31-34 configures the necessary services for GraphQL. Line 34 has the required call to install the authorization rule GraphQL middleware. Please see this link for details on how to configure this for your code. Based on your current code, you will likely need a call to .AddDataLoader() and also .AddUserContextBuilder() (see here).

The remainder is typical ASP.NET Core application configuration. The calls to .AddAuthentcation() and .AddAuthorization() on lines 56-57 are required as usual. The GraphQL HTTP middleware is installed on line 62.

With this setup, you may delete your old GraphQLMiddleware.cs and AuthenticationRequirement.cs files.

'Complex' sample

This sample does not demonstrate authorization, but it shows a more complex configuration with a Startup.cs file, with a much more typical configuration of the builder methods within the AddGraphQL() call.

https://github.com/graphql-dotnet/server/blob/master/samples/Samples.Complex/Startup.cs

Here custom middleware is used and installed on line 58. See this file for the middleware class.

But basically it's pretty similar to the authorization sample above.

from server.

Published https://github.com/graphql-dotnet/authorization/releases/tag/7.0.0

from server.

@julienFlexsoft Either update to fresh GraphQL.Authorization v7 or go on with server bits - what do you like best.

from server.

You should be able to find most other details on GraphQL.NET Server 7's authentication features listed here: https://github.com/graphql-dotnet/server#authorization-configuration

from server.

Alright! Thank you for all the help!

I updated the GraphQL.Authorization to v7 and added the options.User = context.User;. Everything seems to be working but I'll test it further in the coming days.

I am wondering why the the .AddGraphQL() is preferred, is there a difference in terms of performance compared to the middleware? Or will the middleware be phased out in one of the coming releases?

from server.

Assuming that you serialize the ExecutionResult response directly to the output stream, there should be no appreciable difference in performance either way. But I have seen MVC implementations that serialize the ExecutionResult to a string, and then parse the string to a JObject, and then return the JObject from the MVC method to be serialized by ASP.NET Core to the response stream.

We do not plan to phase out IDocumentExecuter; custom installation and use of the necessary DI services are still supported. It's just that the there is a better chance that your code would not need to change across major versions when using the builder methods, and documentation for new features will assume that the builder methods are used to configure GraphQL.NET.

from server.

Closing as answered. Please re-open if you have further questions.

from server.