fix: use request.protocol to check for HTTPS

[mohd-akram]

The header shouldn't be read unless trustProxy is true.

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[gurgunday]

Is there a problem with trusting the header here? We'd at worst be sending secure=true, and if that's not really the case, the browser would ignore it

But I agree with you in principle that proxies should not be trusted when trustProxy is disabled

@fastify/plugins is this breaking?

[mcollina]

lgtm

[mcollina]

I don't think so.

[climba03003]

I don't think always sent secure cookies to the client that pretend to be https is a wrong idea.

Even if the next hop is not a trust proxy, sending secure cookies should not harm. Secure cookies will not set when the end client (broswer) is using http.

[gurgunday]

That was what I thought... but the reason I approved anyway is trustProxy wasn't respected at the end of the day...

I could accept the following:

if (opts.secure === 'auto') {
    if (reply.request.protocol === 'https' || (fastify.trustProxy === true && request.headers['x-forwarded-proto'] === 'https')) {
      opts.secure = true
    } else {
      opts.sameSite = 'lax'
    }
}

However, should be noted that x-forwarded-proto is not the standard, Forwarded is

[mohd-akram]

fastify.trustProxy === true && request.headers['x-forwarded-proto'] === 'https')

This is the same as reply.request.protocol === 'https' AFAICT since it check trustProxy and uses the header if it's available.