How to see the payload sent to my Azure web service
-
Hi all, I have an app service that works fine for most folks. This one client is having an issue and I'm 95% sure they're sending something wrong. So I need to see exactly what payload they're sending. What's the best way to do this in Azure? I thought about Fiddler but doesn't that need to sit on the same machine as the webserver? Anyway... if you could give me some ideas on how I can see this payload I'd greatly appreciate it. Denise
Hypermommy
-
Hi all, I have an app service that works fine for most folks. This one client is having an issue and I'm 95% sure they're sending something wrong. So I need to see exactly what payload they're sending. What's the best way to do this in Azure? I thought about Fiddler but doesn't that need to sit on the same machine as the webserver? Anyway... if you could give me some ideas on how I can see this payload I'd greatly appreciate it. Denise
Hypermommy
Hypermommy wrote:
I thought about Fiddler but doesn't that need to sit on the same machine as the webserver?
No, Fiddler sits on the client computer.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Hi all, I have an app service that works fine for most folks. This one client is having an issue and I'm 95% sure they're sending something wrong. So I need to see exactly what payload they're sending. What's the best way to do this in Azure? I thought about Fiddler but doesn't that need to sit on the same machine as the webserver? Anyway... if you could give me some ideas on how I can see this payload I'd greatly appreciate it. Denise
Hypermommy
That is exactly why you use logging. Elmah can be a good place to start if your application is .NET based. [ELMAH—Home](https://elmah.github.io/) You need to check what is being input, and maintain that as a token. If I had to do this, I would most likely maintain a trace of the exception thread, store the states, or the request object that they had sent including query strings, headers etc, or the account information, and provide the user with a token,
Guid.NewGuid(), in the response along with a message stating something went wrong and ask them to reach me out with that token in order to have that fixed for their account. Using Postman won't help at all, because you are still working on the client-side and not check what is going wrong, and exposing error information on the public internet—even for personal understanding—never results in a good way. Someone might just understand the workflow and use that for nefarious purposes.The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
-
That is exactly why you use logging. Elmah can be a good place to start if your application is .NET based. [ELMAH—Home](https://elmah.github.io/) You need to check what is being input, and maintain that as a token. If I had to do this, I would most likely maintain a trace of the exception thread, store the states, or the request object that they had sent including query strings, headers etc, or the account information, and provide the user with a token,
Guid.NewGuid(), in the response along with a message stating something went wrong and ask them to reach me out with that token in order to have that fixed for their account. Using Postman won't help at all, because you are still working on the client-side and not check what is going wrong, and exposing error information on the public internet—even for personal understanding—never results in a good way. Someone might just understand the workflow and use that for nefarious purposes.The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
Thanks, y'all! Now it seems I just have to learn how to get my setup right on here so I can see answers. :-) But seriously, I do appreciate the help.
Hypermommy
