tuupola / slim-basic-auth

PSR-7 and PSR-15 HTTP Basic Authentication Middleware
MIT License
440 stars 66 forks source link

Specify callback for the relaxed configuration parameter #104

Closed christeredvartsen closed 3 years ago

christeredvartsen commented 3 years ago

Feature request:

Some proxies don't specify the x-forwarded-port header, which renders the 'relaxed' => ['headers'] configuration useless. Would it be a good option to be able to specify a callback for the relaxed configuration key so that one could have extended possibilities to decide on whether or not the request should be accepted?

The callback could for instance have the following signature:

function (Psr\Http\Message\ServerRequestInterface $request) : bool {
    // check details in the request, and return true/false to signal allow/disallow
}

This is of course an edge case, so I fully understand if you feel this should not be implemented in your library. However, if you think the feature sounds interesting I can implement it and add tests and present this as a pull request.

christeredvartsen commented 3 years ago

I just noticed that this functionality has changed a bit in 4.x (removing the 'relaxed' => ['headers'] feature altogether), but the feature request is still valid IMO.

tuupola commented 3 years ago

I am planning to remove this feature from 4.x since IMO it is not responsibility of this middleware to wrangle request protocols based on arbitrary headers user can set. Non encrypted request is insecure even if there was X-Forwarded-Proto and X-Forwarded-Port present.

If user still wants to make this middleware or Slim itself to see an http request with X-Forwarded-Proto and X-Forwarded-Port as https request that can be done with another middleware which is executed first.

Technically there is no difference between setting secure to false and or trusting the headers.

christeredvartsen commented 3 years ago

If user still wants to make this middleware or Slim itself to see an http request with X-Forwarded-Proto and X-Forwarded-Port as https request that can be done with another middleware which is executed first.

Agree, and this will solve my current issue as well.

Anyways, thanks for the great middleware! :heart: