Solved: Apigee is not identifying PUT and PATCH requests

gustavo-rey · 11-24-2023 09:27 AM

Hi everyone.

I'm having a problem with Apigee when trying to make PUT or PATCH requests, I'm receiving a 403 error. In addition, no call appears on the API proxy debug screen.

In my API Products I've enabled all the methods.

As far as I know, the API policies don't matter because I can't see the request in the debug mode. Winch means that the error is happening before Apigee calls the proxy API.

GET and POST are working with no issues.

Does anyone know what can be happening?

Thank you.

dchiesa1

Hi,

As far as I know, the API policies don't matter because I can't see the request in the debug mode. Which means that the error is happening before Apigee calls the proxy API.

I think that's mostly right and plausible. I would say it a little less definitively, though.

if you have started a debug session
and you are sending requests into...what you think is an Apigee proxy
and you are not seeing those requests in the debug session in the UI,
then,
probably the policies in the API proxy don't matter. The request is apparently not reaching that API proxy.

But note, "probably". Before we can be certain, let's take a step back and understand some possible reasons why you would observe what you are observing. Some possible explanations

You have set a "filter" on the debug session. In Apigee it is possible to start s debug session with a condition, such that the debug session captures ONLY GET requests. Or Only POST. Or only requests that are either GET or POST, but not PUT or PATCH. In that case, your request might be reaching the proxy, and might be getting handled correctly by the proxy, but you see no evidence of that in the debug session. This seems unlikely, though, because if you had set a filter for the debug session, to exclude PUT and PATCH, you would know that you did so.
more likely, your outbound requests are being blocked by something other than Apigee, something between the client and Apigee. A network device or firewall or proxy.

What could it be? There is an interesting bit of information in your analysis; you noted that the 403 message included this:

<title>403</title>403 Forbidden

That is not a message that gets returned by Apigee, by default. You could create an Apigee proxy to return that, but the Apigee system itself does not return messages that look like that, even when there is a 403 response . So what system DOES return a message that looks like that?

Cloud Armor (example). Or the Identity-Aware Proxy in google cloud. Not sure if others.

Why? I don't know. Is it possible you have a cloud armor rule that explicitly blocks PUT and PATCH?

Please check that.

View solution in original post

dchiesa1

Hi,

As far as I know, the API policies don't matter because I can't see the request in the debug mode. Which means that the error is happening before Apigee calls the proxy API.

I think that's mostly right and plausible. I would say it a little less definitively, though.

if you have started a debug session
and you are sending requests into...what you think is an Apigee proxy
and you are not seeing those requests in the debug session in the UI,
then,
probably the policies in the API proxy don't matter. The request is apparently not reaching that API proxy.

But note, "probably". Before we can be certain, let's take a step back and understand some possible reasons why you would observe what you are observing. Some possible explanations

You have set a "filter" on the debug session. In Apigee it is possible to start s debug session with a condition, such that the debug session captures ONLY GET requests. Or Only POST. Or only requests that are either GET or POST, but not PUT or PATCH. In that case, your request might be reaching the proxy, and might be getting handled correctly by the proxy, but you see no evidence of that in the debug session. This seems unlikely, though, because if you had set a filter for the debug session, to exclude PUT and PATCH, you would know that you did so.
more likely, your outbound requests are being blocked by something other than Apigee, something between the client and Apigee. A network device or firewall or proxy.

What could it be? There is an interesting bit of information in your analysis; you noted that the 403 message included this:

<title>403</title>403 Forbidden

That is not a message that gets returned by Apigee, by default. You could create an Apigee proxy to return that, but the Apigee system itself does not return messages that look like that, even when there is a 403 response . So what system DOES return a message that looks like that?

Cloud Armor (example). Or the Identity-Aware Proxy in google cloud. Not sure if others.

Why? I don't know. Is it possible you have a cloud armor rule that explicitly blocks PUT and PATCH?

Please check that.

gustavo-rey

@dchiesa1 thank you for your answer.

First of all, about the filters in the debug mode, that's true, I didn't add any filters to start the session.

Filter = None(All Transaction)

What you said about Apigee not returning messages like that is very interesting so we can rule out any problem on Apigee's side.

However, about the Cloud Armor, yes, we can probably have some special rule there, but the access is blocked for me to this console (https://console.cloud.google.com/net-security/securitypolicies/managedprotection), if this is the correct link.

So, I'm opening a request with the Cloud team to check, and as soon as I find out where this policy is, I'll get back to you with this information.

Thank you