Usefulness of DgsCustomContextBuilder

[karhig]

I thought DgsCustomContextBuilder would be the place to extract information from the headers, such as decoding a jwt to make it available to requests. The default context provides access to headers, but becaue the build() method of DgsCustomContextBuilder is parameterless, I don't understand how to do this, or how to make use of it in general. The documentation isn't very illuminating.

Could someone help me out?

[eblanchette]

I'm in the same boat. Maybe this is a spring boot configuration?

[victorlevasseur]

Meanwhile, I successfully retrieved the headers but only from a datafetcher or dataloader.
You must not provide any custom DgsCustomContextBuilder for this to work:

  public static Optional<String> getBearer(DgsDataFetchingEnvironment env) {
    DgsContext context = env.getContext();
    DefaultRequestData requestData = (DefaultRequestData)context.getCustomContext();
    return Optional.ofNullable(requestData)
        .map(DefaultRequestData::getHeaders)
        .flatMap(headers -> Optional.ofNullable(headers.get("Authorization")))
        .flatMap(headerValues -> headerValues.stream().findFirst());
  }

  public static Optional<String> getBearer(BatchLoaderEnvironment env) {
    DgsContext context = env.getContext();
    DefaultRequestData requestData = (DefaultRequestData)context.getCustomContext();
    return Optional.ofNullable(requestData)
        .map(DefaultRequestData::getHeaders)
        .flatMap(headers -> Optional.ofNullable(headers.get("Authorization")))
        .flatMap(headerValues -> headerValues.stream().findFirst());
  }

[srinivasankavitha]

@karhig, @eblanchette - We will add better documentation with examples for this. In short, the build() method gives you access to a new instance of the context. You can then add whatever setters you need to the custom context implementation to pass down the required context to child fetchers. Note that this context should have the scope of the request (not local context specific to data fetchers, you can use the local context in dfe for that).

MyCustomContext customContext = DgsContext.getCustomContext(dfe);
customContext.setCustomField(someData);

Where MyCustomContext is your implementation

@Component
public class MyContextBuilder implements DgsCustomContextBuilder<MyContext> {
    @Override
    public MyContext build() {
        return new MyContext();
    }
}

public class MyContext {
   private String customState;

    public String setCustomState(String customInput) {
        customState = customInput
    }
}

Hope that helps.

[eblanchette]

Yes, that makes sense. I assumed this context would be pre-filled with http header information. How would one get a handle on a http header for authentication? Use a servlet filter with a ThreadLocal variable?

Thanks,

Eric

[paulbakker]

Actually, I see why the requestdata is confusing. We should fix and/or document that. We use it internally for that, but setting the data is done elsewhere.

Using a filter is a good way to do so.

[paulbakker]

We have implemented some new features since this thread.

DgsCustomContextBuilderWithRequest
A new interface DgsCustomContextBuilderWithRequest has been introduced with the following signature:

interface DgsCustomContextBuilderWithRequest<T> {
    fun build(extensions: Map<String, Any>?, headers: HttpHeaders?, webRequest: WebRequest?): T
}

Similar to the original DgsCustomContextBuilder you can register an implementation of this interface as a Spring bean with @Component. If an implementation for both are found, only DgsCustomContextBuilderWithRequest is used.

The existing interface still exists for backward compatibility.

@RequestHeader
Note that if you just want to get a header in your data fetchers, you can use the @RequestHeader annotation:

@DgsData(parentType = "Query", field = "usingHeader")
fun usingRequestHeader(@RequestHeader myheader: String?): String