I was just bitten hard by the new behavior that not all header checks for REST can be turned off in the config.ini: I'm always getting::

 { "error": { "status": 400, "msg": "Required Header Missing" } }

Unfortunately I've not found anything about this in any of the upgrading docs.

Looks like the 'Origin' header check is hard-coded in roundup/cgi/client.py for the API, in handle_rest we have::

        if not self.is_origin_header_ok(api=True):
            if 'HTTP_ORIGIN' not in self.env:
                msg = self._("Required Header Missing")
            else:
                msg = self._("Client is not allowed to use Rest Interface.")

            # Use code 400. Codes 401 and 403 imply that authentication
            # is needed or authenticated person is not authorized.
            # Preflight doesn't do authentication.
            output = s2b(
                '{ "error": { "status": 400, "msg": "%s" } }' % msg)
            self.reject_request(output,
                                message_type="application/json",
                                status=400)
            return

So this does not use the csrf_enforce_header_origin in the config.
From the comments it looks like this might be intended to only be hit on a preflight check. But it is hit any time a POST is issued to the tracker. Even when authenticated. I'm using Kerberos Authentication behind an apache2 webserver.

Is this intentional?
I can see why one would enforce at least one header with REST but unfortunately I have a very important legacy app that I have no influence on.

Hi Ralf:

In message <1696851823.07.0.447405379261.issue2551294@roundup.psfhosted.org>,
Ralf Schlatterbeck writes:
>New submission from Ralf Schlatterbeck:
>
>I was just bitten hard by the new behavior that not all header checks for REST can be turned off in the config.ini: I'm always getting::
>
> { "error": { "status": 400, "msg": "Required Header Missing" } }

Which headers are you sending? IIRC there are to places with that
output for RES. Origin and X-requested-With. The latter can be
disabled. Do you have x-requested-with turned off?

Can you tell if the client is sending the Origin header?

>Unfortunately I've not found anything about this in any of the upgrading docs.

Yeah, we don't have a lot of REST users, so....

Which version did you upgrade from when it was working?

>Looks like the 'Origin' header check is hard-coded in roundup/cgi/client.py
>for the API, in handle_rest we have::
>
>        if not self.is_origin_header_ok(api=True):
>            if 'HTTP_ORIGIN' not in self.env:
>                msg = self._("Required Header Missing")
>            else:
>                msg = self._("Client is not allowed to use Rest Interface.")
>
>            # Use code 400. Codes 401 and 403 imply that authentication
>            # is needed or authenticated person is not authorized.
>            # Preflight doesn't do authentication.
>            output = s2b(
>                '{ "error": { "status": 400, "msg": "%s" } }' % msg)
>            self.reject_request(output,
>                                message_type="application/json",
>                                status=400)
>            return
>
>So this does not use the csrf_enforce_header_origin in the config.

>>From the comments it looks like this might be intended to only be
>hit on a preflight check. But it is hit any time a POST is issued to
>the tracker.

That sounds right. Post's do a pre-flight IIRC and they should always
send an Origin.

From the docs on preflight:

   Also these requests bypass CSRF checks except for the Origin header
   check which is always run for preflight requests.

>Even when authenticated. I'm using Kerberos Authentication behind an
>apache2 webserver.

I think a csrf request would get your session tokens.

>Is this intentional?

IIRC forcing origin is intentional.

>I can see why one would enforce at least one header with REST but
>unfortunately I have a very important legacy app that I have no
>influence on.

You believe it's not sending an Origin? IIRC there is a different
error if the Origin doesn't match the Roundup server. But
allowed_api_origins might be of use if you think that's the issue.

Sorry I don't have a good answer for you.

I've just read up a bit on CSRF. Looks like you're right to hard-code this and that we should get our application fixed. Thanks for looking into this

I'm closing this issue.