Hard to tell.
What is the OS of the server and client?
What is the OS of the client?
In which language is the client developed?
Is the HTTP request arriving correctly at the server?
Have you debugged the server to check how the requests are arriving and what point is returning 403.
I believe you will have to do more investigation, specially server-side, to check if and how the request is arriving at it.
Hello,
Windows server - client is also Windows (FMX).
I made a lots of tests - looks like the requests to the server is sent like: https://xxxxxx/api/MyService/Echo2?A='123'
When I tried to send it in SOAPUI with the same format I got same error "403 Forbidden".
Looks like the browser is replacing the ' character with %27.
When I call the function is this format in SOAPUI it works also. https://xxxxxx/api/MyService/Echo2?A='123'
Strange thing is on localhost it's working fine.
So where the format change is done??
The correct request is with %27, that's percent encoded. I don't know what is SOAPUI. Don't you have proxies, intermediate servers between the client and server that modify the request? My guess is that the request is not reaching the server the way it should, if it's reaching the server at all.
If you are requesting it from browser, you can put here the full detail requests to see if the response is actually coming from the XData server.
Looks like I found the root cause.
I am using Microsoft Azure with Application Gateway.
Also I have activated the WAF (Web Application Firewall).
With the standard settings (prevention) without any rules.
When I deactivate the WAF the "string parameter requests" are working fine.
So now I have to find the best rule to "allow" XData requests with string parameters.
Does someone else has some experience with Azure WAF?
So Azure Web Application Firewall (WAF) is blocking the requests (by default) with this rule:
REQUEST-949-BLOCKING-EVALUATION - Inbound Anomaly Score Exceeded - BLOCK
I guess this is because the request what XData is generated is not well formed.
There should be no string start and end characters in the request URI - 'String'.
Without the string markers the server gives an OK response and firewall is not blocking.
Is there a reason why XData is formatting strings like that?
Same problem is when I use other 3rd party tool (e.g. SOAPUI) in this format.
When I enter the same url to the browser - it coverts the string markers into "%27" - which is also working (but without this it would be better formatted).
Strings parameters should have no string markers in the url.
Can this be fixed in the near future of can/should I modify the XData.Client.TXDataInvoker.Execute method?
XData is working like that since almost 10 years now. The single quote ' is a reserved char and doesn't need to be encoded. Can't you simply change your Azure rule to the correct one?
Azure rule cannot be removed - it is global and mandatory and default for all Azure WAFs.
As I said it is not a problem of the server.
Even if you enter the url with the string quote it will be replaced before sending to the server - because this character for strings should be not there.
URL strings parameters don't need this "Delphi specific chars".
It's not "Delphi specific char". It's a regular query string.
If that was the case, you wouldn't have a problem with the server. I believe it's Azure who is blocking th request and not forwarding it to the server.
