You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our microservice architecture, we have Authorization headers to gate access to our services. In this case, our gateway service needs to pass along expected authorization headers to our federated service.
Problem
On initialization of the gateway service, the willSendRequest callback will only fire when a GraphQL request is executed, which makes sense. But there is not configuration option available to send an initial authorization header.
Therefore, we can't use the global context object on the federated service to throw an AuthenticationError.
On the federated service, this is ideally how we would configure the server. It's important to note the business logic of the global context object here.
However, if you use this, the gateway service will receive the Not authenticated error thrown by the context object of the federated service.
The intuition is that a request to a service behind our gateway should carry an Authorization header with a known secret or a JWT in a way that each service knows the secret to validate the authenticity of the JWT that's passed. On initialization of the Gateway, there is no user context to pass along, so an expected secret should be supported.
Please let me know if you need more detail to understand this request.
Despite that, got it to work! Loving this federation pattern so far.
The text was updated successfully, but these errors were encountered:
@calebfaruki we are working on a design that lets you pull the service config with a lot more control! We want to separate willSendRequest from fetching service capabilities. This was a major source of confusion in stitching and we think not doing detch on startup is probably the better long term solution. We will have more details on this very soon!
Noting that this PR conflicts directly with what @jbaxleyiii said above - I moved forward with that PR, but was missing the context mentioned by James to decide against this. For now, the mentioned PR unlocks a viable solution for this.
Context
In our microservice architecture, we have Authorization headers to gate access to our services. In this case, our gateway service needs to pass along expected authorization headers to our federated service.
Problem
On initialization of the gateway service, the
willSendRequest
callback will only fire when a GraphQL request is executed, which makes sense. But there is not configuration option available to send an initial authorization header.Therefore, we can't use the global context object on the federated service to throw an
AuthenticationError
.Source Code
From the gateway app:
On the federated service, this is ideally how we would configure the server. It's important to note the business logic of the global context object here.
However, if you use this, the gateway service will receive the
Not authenticated
error thrown by the context object of the federated service.The intuition is that a request to a service behind our gateway should carry an Authorization header with a known secret or a JWT in a way that each service knows the secret to validate the authenticity of the JWT that's passed. On initialization of the Gateway, there is no user context to pass along, so an expected secret should be supported.
Please let me know if you need more detail to understand this request.
Despite that, got it to work! Loving this federation pattern so far.
The text was updated successfully, but these errors were encountered: