`FastifyInstance.auth0Client` causes a type error when using HTTPS or HTTP2

[JesseTG]

Description

I'm using @auth0/auth0-fastify to implement authentication in my app. I've started implementing HTTPS support, but noticed some TypeScript issues that prevent it from working. I'm not sure if this indicates a TypeScript issue or a lack of HTTP2 support. Details follow.

When I initialize my app's FastifyInstance like so, then its type signature is parameterized like so:

const fastify = Fastify({
  http2: true,
  https: {
    allowHTTP1: true,
    key: HTTPS_KEY_PATH ? readFileSync(HTTPS_KEY_PATH) : undefined,
    cert: HTTPS_CERT_PATH ? readFileSync(HTTPS_CERT_PATH) : undefined,
  },
});

fastify.get('/', async (request, reply) => {
  const user = await request.server.auth0Client?.getUser({ request, reply });
  // Other stuff...
});

/*
const fastify: Fastify.FastifyInstance<
  Http2SecureServer<
    typeof IncomingMessage,
    typeof ServerResponse,
    typeof Http2ServerRequest,
    typeof Http2ServerResponse
  >,
  Http2ServerRequest,
  Http2ServerResponse<Http2ServerRequest>,
  Fastify.FastifyBaseLogger,
  Fastify.FastifyTypeProviderDefault
> & PromiseLike<TheSameStuff>
*/

The problem is that @auth0/auth0-fastify's declaration-merged FastifyInstance assumes the default parameterization through its use of StoreOptions, which in turn only uses the default parameters of FastifyRequest and FastifyReply.

declare module 'fastify' {
  interface FastifyInstance {
    auth0Client: ServerClient<StoreOptions> | undefined;
  }
}

export interface StoreOptions {
  request: FastifyRequest;
  reply: FastifyReply;
}

End result? These compiler errors:

Type 'FastifyRequest<RouteGenericInterface, Http2SecureServer<typeof IncomingMessage, typeof ServerResponse, typeof Http2ServerRequest, typeof Http2ServerResponse>, ... 5 more ..., ResolveFastifyRequestType<...>>' is not assignable to type 'FastifyRequest<RouteGenericInterface, RawServerDefault, IncomingMessage, FastifySchema, FastifyTypeProviderDefault, unknown, FastifyBaseLogger, ResolveFastifyRequestType<...>>' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
  Type 'Http2ServerRequest' is missing the following properties from type 'IncomingMessage': headersDistinct, trailersDistinct

Type 'FastifyReply<RouteGenericInterface, Http2SecureServer<typeof IncomingMessage, typeof ServerResponse, typeof Http2ServerRequest, typeof Http2ServerResponse>, ... 5 more ..., unknown>' is not assignable to type 'FastifyReply<RouteGenericInterface, RawServerDefault, IncomingMessage, ServerResponse<IncomingMessage>, unknown, FastifySchema, FastifyTypeProviderDefault, unknown>'.
  Type 'Http2ServerRequest' is missing the following properties from type 'IncomingMessage': headersDistinct, trailersDistinct

Reproduction

To reproduce this, try to build the aforementioned code snippets.

Environment

• @auth0/auth0-fastify@1.2.0
• fastify@5.6.1
• typescript@5.9.3

[frederikprijck]

Thanks for reaching out. I was able to very easily reproduce this with your provided steps.

I wanted to understand if this is more of a type issue or a fundamental issue, but it seems like to be more of a type issue as the following worked fine for me at run-time:

 const user = await request.server.auth0Client?.getUser({ request: request as unknown as FastifyRequest, reply: reply as unknown as FastifyReply });

Obviously, this is not the correct solution, but would you perhaps be able to confirm on your side if this also works, to help me understand if you are also looking purely at a type issue?

[frederikprijck]

I have opened a PR that works with and without http2: #38

However, as this feels a bit verbose in terms of generics, I want to see if there's something we can improve further.

[frederikprijck]

I digged a bit deeper on the impact of the changes in #38, and based on what I can see it should be backwards compatible.

Any chance you can confirm it would resolve the issue in your case as well?

I also have a follow-up PR (#39) that I want to test further, but it would remove the need to pass any request and reply to begin with, which would have avoided this problem altogether.

[JesseTG]

I'll check today, thanks for looking into this!

[JesseTG]

Thanks for reaching out. I was able to very easily reproduce this with your provided steps.

I wanted to understand if this is more of a type issue or a fundamental issue, but it seems like to be more of a type issue as the following worked fine for me at run-time:

const user = await request.server.auth0Client?.getUser({ request: request as unknown as FastifyRequest, reply: reply as unknown as FastifyReply });

Obviously, this is not the correct solution, but would you perhaps be able to confirm on your side if this also works, to help me understand if you are also looking purely at a type issue?

I can confirm that applying the workaround in the quote works on my end. I do get a runtime error when setting up a WebSocket, but I'm not yet sure if that's related to this library. Will follow up if it turns out to be so.

Here's the error message if you're curious:

write EPROTO 1C4E0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:openssl\\ssl\\record\\rec_layer_s3.c:916:SSL 
alert number 40

[JesseTG]

I digged a bit deeper on the impact of the changes in #38, and based on what I can see it should be backwards compatible.

Any chance you can confirm it would resolve the issue in your case as well?

I also have a follow-up PR (#39) that I want to test further, but it would remove the need to pass any request and reply to begin with, which would have avoided this problem altogether.

Got any good reading on using a TypeScript library directly from a Git repo (as opposed to an NPM package)? I'll happily try it out if I can figure out how without spending an inordinate amount of time on it again.

[frederikprijck]

You should be able to do:

• git clone https://github.com/auth0/auth0-fastify.git
• cd auth0-fastify
• git checkout chore/more-flexible-request-reply
• npm i
• npm run build
• cd packages/auth0-fastify
• npm pack

That gives you a .tgz file, than you can go to your project and do:

• npm uninstall @auth0/auth0-fastify
• npm i ..path/to/auth0-fastify/packages/auth0-fastify/auth0-auth0-fastify-1.2.0.tgz

You may need to clear your cache if it does not properly install the changes.

Doing this should allow you to run your application with the unpublished version of the SDK.
Additionally, you can also move the .tgz file to your project, so that you can check it in and run CI if you need that for additional verification.

[JesseTG]

Thank you for your patience. Now that I've had a chance to test this, I can confirm that it builds fine and the backend listens for HTTPS connections just fine.

However, I do get this error;

ErrorEvent {
  Symbol(kTarget): WebSocket {
    _events: [Object: null prototype] {},
    _eventsCount: 0,
    _maxListeners: undefined,
    _binaryType: 'nodebuffer',
    _closeCode: 1006,
    _closeFrameReceived: false,
    _closeFrameSent: false,
    _closeMessage: <Buffer >,
    _closeTimer: null,
    _errorEmitted: true,
    _extensions: {},
    _paused: false,
    _protocol: '',
    _readyState: 3,
    _receiver: null,
    _sender: null,
    _socket: null,
    _bufferedAmount: 0,
    _isServer: false,
    _redirects: 0,
    _autoPong: true,
    _url: 'wss://localhost:3000/signal',
    _req: null,
    Symbol(shapeMode): false,
    Symbol(kCapture): false
  },
  Symbol(kType): 'error',
  Symbol(kError): Error: write EPROTO 38D00000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:openssl\ssl\record\rec_layer_s3.c:916:SSL alert number 40

      at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:87:19)
      at WriteWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
    errno: -4046,
    code: 'EPROTO',
    syscall: 'write'
  },
  Symbol(kMessage): 'write EPROTO 38D00000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:openssl\\ssl\\record\\rec_layer_s3.c:916:SSL alert number 40\n'
}

This error occurs when trying to establish a WebSocket connection with ws. I'm not sure if this error is due to Fastify, ws, or (my own) user error. What do you think?

[JesseTG]

Ah, it was an unrelated issue.

In that case, I'm good to go with the fix in #38 !

[frederikprijck]

Apologies for the delay, but this should be resolved with the v1.3.0 release we did.