endpoints.xhr.Endpoints offers to no way to set withCredentials in the XMLHttpRequest

[esarbe]

To be able to use cookies or authentication headers for cross-site requests, the XMLHttpRequest.withCredentials property must be set.

See https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials

Alas, endpoints.xhr.Endpoints offers no way to set this.

[julienrf]

I am not sure if we should add an option to the xhr.Endpoints interpreter that would set this flag for every request or if this is a setting you want to define per endpoint and that needs to be taken into account by both the server and the client.

The important question here is “should it (the fact that we need to set the withCredentials property) be part of the endpoint description or not?”. Being part of the endpoint description means that clients, server and documentations can leverage this information (for instance, the server interpreter could use this information to accordingly set-up the Access-Control-Allow-Origin response header).

[esarbe]

I'm not convinced that it (the fact that we need to set the withCredentials property) it should be part of the endpoint description. It's pretty much independent from the service description, depending on the implicit knowledge that there is a cookie/header involved and that the request is cross-origin.

I guess it could be part of the service description, but that would require some kind of dedicated authentication/authorization language/algebra...?

[julienrf]

I guess it could be part of the service description, but that would require some kind of dedicated authentication/authorization language/algebra...?

Yes, but so far we don’t have the concept of response headers, which means that you’d have to write an Endpoint constructor:

trait Cors extends endpoints.algebra.Endpoints {
  def corsEndpoint[A, B](
    origin: String,
    request: Request[A],
    response: Response[B]
  ): Endpoint[A, B]
}

And then implement it on server interpreters to set the Access-Control-Allow-Origin response header to the origin value, and implement it on client interpreters to set the withCredentials property to true.

That being said, if you’re not convinced that it should be part of the endpoint description, you could just specialize the xhr.Endpoints interpreter to set the withCredentials property:

trait CorsEndpoints extends xhr.Endpoints {
  override def request[A, B, C, AB, Out](
    method: Method,
    url: Url[A],
    entity: RequestEntity[B],
    docs: Documentation,
    headers: RequestHeaders[C]
  )(implicit tuplerAB: Tupler.Aux[A, B, AB], tuplerABC: Tupler.Aux[AB, C, Out]): Request[Out] =
    new Request[Out] {
      def apply(abc: Out) = {
        val (ab, c) = tuplerABC.unapply(abc)
        val (a, b) = tuplerAB.unapply(ab)
        val xhr = makeXhr(method, url, a, headers, c)
        xhr.withCredentials = true
        (xhr, Some(entity(b, xhr)))
      }

      def href(abc: Out) = {
        val (ab, _) = tuplerABC.unapply(abc)
        val (a, _) = tuplerAB.unapply(ab)
        url.encode(a)
      }
    }
}

And then mix CorsEndpoints to your client implementation. (but eventually, we should add an option for that in endpoints so that you wouldn’t need to override the request constructor).

[esarbe]

I've now used a second-ish approach to solve my particular problem; thus far it works, which is nice.

I however still don't have a clear understanding whether or not this is part of the endpoint description. If I look at i.e. http4s this seems to be a separate concern.