You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 10, 2024. It is now read-only.
One would expect security headers to be recognised from the scheme and not to be stripped from the request. Declaring them for each entry point is redundant.
The text was updated successfully, but these errors were encountered:
That's a great catch, thanks! 👍 I'll be sure to fix it. A quick question on this - could you make use of the security layer here? I'd love a little more context on the usage of the header in the application (if it's aside from authentication).
hi, i am having a problem authenticating with passport-jwt following @gciatto 's approach as shown in #102
would it be a victim of the header removal as well !?
i noticed in passport's strategy verify function the token payload is received in the request, but seems to be unauthorized funrther along the middleware, in Osprey.
Custom headers used to describe a security scheme get removed from the request if only the security scheme is referenced, e.g.:
In this example the
custom-token
header is stripped from the request. This works:One would expect security headers to be recognised from the scheme and not to be stripped from the request. Declaring them for each entry point is redundant.
The text was updated successfully, but these errors were encountered: