Do not unset Remote-User on the frontend
The Remote User is managed on the backend apache which will unset it anyway.
-
Owner
Are you sure ?
Ony the frontend sees client certificate, so if the remote-user is set using values from the certificate it needs to be unset for the case where client does not provide such certificate but sets this header.
/cc @luke
-
Owner
This feature, where it is used (single place), it is only implemented via direct access to the apache backend. ERP5 backend already unset (and set) Remote-User based on SSL Certificate Information, so this unset on this commit is just userless noise for now. (Apache backend keeps unseting Remote-User as usual).
However, once we can authenticate via frontend (relying on caucase and whatever else required), the unset might be reintroduced along with all the code to implement the feature.
-
Owner
So you are knowingly removing something which is not used yet but which is here to prepare future extension that we want to eventually reach. Why ? Is it causing issues ?
Forgetting to later reintroduce this would open a critial authentication bypass vulnerability and "normal" usage will appear working just fine (so this issue, as many security vulnerabilities, will never be discovered on its own). I'm not fond of "let's re-add it later" approach for security.
-
Owner
It is not really possible to forget this one, specially because "Remote-User" is an arbitrary value, it is not writen in ERP5 code base, so I'm not even sure the name we end up using will be really "Remote-User". In any case, it will be required to port code from apache backend to frontend, which implies we are going to port the unset and set in the same way.
-
Owner
It is not really possible to forget this one
I still completely disagree, but whatever.
"Remote-User" is an arbitrary value [...] I'm not even sure the name we end up using will be really "Remote-User"
Fair enough, this means this will need to be specified by frontend (and documented in frontend doc). Frontends will anyway need to provide more than one value from seen client certificate (out the top of my head: serial, subject, some CA identifier, and ideally any arbitrary certificate extension...). Then it needs to implement this kind of protection for all headers it will reserve, and only once all that is done the backends may use these values.
So I agree with removing this cleanup now for this reason.