grpc-web: Using server streaming with authboss the call remains in pending state (and doesn't work)

Versions of relevant software used

github.com/improbable-eng/grpc-web v0.14.0

What happened

I have been using grpc-web for a long time (it’s such a pleasure, THANKS!).

I’m using it with authboss too.

Today I had to test the gRPC server streaming and after HOURS of trying I found a strange issue described below:

• main.go:

package main

import (
	"github.com/volatiletech/authboss/v3/remember"
	"net/http"

	"github.com/go-chi/chi/v5"
	"github.com/go-chi/chi/v5/middleware"
	_ "github.com/volatiletech/authboss/v3/auth"
	_ "github.com/volatiletech/authboss/v3/logout"
)

func main() {
  // ... get config and db
  authb := InitAuthboss(config, db)
	chiRouter := chi.NewRouter()
  grpcwebServer := grpcweb.WrapServer(grpc.NewServer())

	chiRouter.Use(authb.LoadClientStateMiddleware, remember.Middleware(authb))

	chiRouter.Group(func(r chi.Router) {
		r.Use(authboss.Middleware2(authb, authboss.RequireNone, authboss.RespondUnauthorized))
		r.Post("/grpc", grpcWebServer.ServeHTTP)
	})

	chiRouter.Group(func(r chi.Router) {
		r.Mount(config.AuthURL, http.StripPrefix(config.AuthURL, authb.Config.Core.Router))
	})

	// ... startServer
}

func InitAuthboss(config *Config, dbPG *DB) *authboss.Authboss {
	var (
		ab                 = authboss.New()
		database           = newDBStorer(config, dbPG)
		cookieStoreKey, _  = base64.StdEncoding.DecodeString(config.CookieStoreKey)
		sessionStoreKey, _ = base64.StdEncoding.DecodeString(config.SessionStoreKey)
		cookieStore        = abclientstate.NewCookieStorer(cookieStoreKey, nil)
		sessionStore       = abclientstate.NewSessionStorer(config.ProjectName, sessionStoreKey, nil)
		cstore             = sessionStore.Store.(*sessions.CookieStore)
	)
	cookieStore.HTTPOnly = true
	cookieStore.Secure = config.IsProduction
	cookieStore.Domain = config.CookiesDomain
	cookieStore.SameSite = http.SameSiteStrictMode
	cookieStore.MaxAge = int(config.CookiesRemembermeMaxageTime.Seconds())
	cstore.Options.HttpOnly = true
	cstore.Options.Secure = config.IsProduction
	cstore.Options.Domain = config.CookiesDomain
	cstore.Options.SameSite = http.SameSiteStrictMode
	cstore.Options.MaxAge = int(config.CookiesSessionMaxageTime.Seconds())
	ab.Config.Paths.RootURL = config.SiteURL
	ab.Config.Storage.Server = database
	ab.Config.Storage.SessionState = sessionStore
	ab.Config.Storage.CookieState = cookieStore
	ab.Config.Modules.LogoutMethod = "GET"
	ab.Config.Core.ViewRenderer = defaults.JSONRenderer{}
	defaults.SetCore(&ab.Config, true, false)
	ab.Config.Core.Redirector = &defaults.Redirector{Renderer: &defaults.JSONRenderer{}, CorceRedirectTo200: true}

	err := ab.Init()
	if err != nil {
    panic(err)
  }

	return ab
}

I’m trying to use protobuf-ts but I don’t get messages from server until connection is closed.

I’m using Svelte 3 like this:

<script lang="ts">
  import { onDestroy, onMount } from "svelte";

  const transport = new GrpcWebFetchTransport({
    baseUrl: "/",
    format: "binary",
  });

  const service = new EventServiceClient(transport);

  const abortController = new AbortController();

  onMount(async () => {
    const call = service.flow({}, { abort: abortController.signal });

    for await (const response of call.responses) {
      console.log("got another response!", response);
    }
  });

  onDestroy(() => abortController.abort());
</script>

The call in in pending state for about 2.2 min. After that I get all messages logged in console.

If I change this line:

chiRouter.Use(authb.LoadClientStateMiddleware, remember.Middleware(authb))

to:

chiRouter.Use(remember.Middleware(authb))

(removing authb.LoadClientStateMiddleware) it works!

Why?

Can you suggest me something?

[johanbrandhorst]

Sounds like some sort of timeout is being hit. I don’t know why the middleware is causing the server to wait, I can’t see it doing anything suspicious with the request body at a first glance. I’d probably just try and debug it more!

[frederikhors]

unless you’re using websockets and it’s done by our websocket library

Nope.