2.) The second question is a bit more complex. And its concerning your Go-Fiber example implementation in your go sdk. These lines here: https://github.com/supertokens/supertokens-golang/blob/master/examples/with-fiber/main.go#L119-L137 show that you are using the NewFastHTTPHandler function from fastHTTP that says in its documentation: "NewFastHTTPHandler wraps net/http handler to fasthttp request handler, so it can be passed to fasthttp server. While this function may be used for easy switching from net/http to fasthttp, it has the following drawbacks comparing to using manually written fasthttp: missing fasthttp functionatlity and slower speed. Now the question, it shouldn't be to hard to directly have a version of your session.VerifySession middleware that can handle a fasthttp request. I've looked through the implementation and only a few minor details would be needed to change. I'm just hesitating on how to best implement it: Either as PR directly to your GO SDK 2.) or some how write my own verifySession handler outside your library which looks really hard, because some internal classes are not exported which I would need. Any ideas on how to go about this, without directly forking your go sdk and using the then modified sdk in my projects?

hey @8bitjonny

Okay I just had a deeper dive into Supertokens and my problem is bigger than I thought. Because, yes, your

session.VerifySession

expects to work with the standard

http.ResponseWriter

and

http.Request

objects, but it reaches way deeper than I thought. Because

session.VerifySession

passes those http/net types down to

recipeInstance.APIImpl.VerifySession

which in turn calls

options.RecipeImplementation.GetSession

and

options.RecipeImplementation.RefreshSession

both of which also use more than a handful of http Cookie or Header utility functions. So the first proposal of adding fastHttp support to your GoSDK as a PR is fairly ambitious because of all the interfaces and functions that currently rely on http/net EVEN if we only consider only those supertokens methods that are needed for the VerifySession to work. And the second proposal of making more of the superTokens types and interfaces publicly importable is really nice of you to offer but I'm currently a bit hesitant because I didn't think that I'd need to reimplement that much logic from scratch.

Also, it's worth mentioning that we are working on changing GetSession so that it takes in just an access token instead of http req / resp. That being said, when using this method, you will have to propagate changes to the access token to the frontend yourself - but it will make it so that you don't need to use fastHTTP.

Uh, nice. Looking forward to that change 👍