TXDataWebClient.RawInvokeAsync and Post

Is it possible to call TXDataWebClient.RawInvokeAsync as a POST rather than a GET?

I think it figures that out automatically if your service interface has [HttpPost] as an attribute instead of [HttpGet]. I had an issue trying to upload a large file using HttpGet but it exceeded some limit or other, but moving it to HttpPost and voila... no issues. Likely something you would need to do for any sizeable images or things like that. I don't know what the HttpGet limit is in this case... 8k maybe? Not huge by any means. I've not hit a limit on HttpPost but haven't tried much beyond 10MB.

1 Like

Thanks. I'll try that - it is nothing to do with size, just a login, but a Get leaves the password in the IIS log files

Interesting. Just out of curiosity, where does IIS enter the mix in your deployment? I've been assuming that a Web Core client connecting to XData/Sparkle over SSL is safely protected from prying eyes and web server logs, but perhaps I shouldn't be so cavalier about such things. I know I can see the details of the requests going back and forth in the Chrome debug tools from the client, but hopefully none of that is visible to anyone else?!

we sometimes map through IIS to the xdata server - useful if clients have port "issues"

Correct, thanks for helping @AndrewSimard .

Like any SSL encrypted communication, it prevents man-in-the-middle attacks, yes, but not web server logs. The other end (IIS) receives the communication unencrypted and what it does with it it's out of Sparkle control. But web logs are common and useful, and the requested URL is indeed logged. So it's not very secure to send sensitive information in URL because of such logs.

I explain that explicitly in my webinar about cloud services. The part of the video I talk about it is here: Cloud Services with Delphi: Don’t Make These Mistakes: Live webinar replay - YouTube.

Watch out for more webinars like this by subscribing to the TMS BIZ: Behind the scenes webinar series.

1 Like

That was a good session. Many great topics.

Regarding the issue at hand, good to know about IIS or web server logs in general. Sometimes it is easy to overlook things like this when a solution is otherwise working well. Trivial to change services to use [HttpPost] instead of [HttpGet] if they pass protected information like passwords. Also a good reminder to not be too dependent on things like SSL. And to not have intermediaries like IIS if possible. And also a good idea to ensure access to web server logs is reasonably protected as well.