We are developing a chatbot to handle internal and external processes for a local authority. We are trying to display contact information for a particular service from our api endpoint. The HTTP request is successful and delivers, in part, exactly what we want but there's still some unnecessary noise we can't exclude.
We specifically just want the text out of the response ("Response").
Logically, it was thought all we need to do is drill down into ${dialog.api_response.content.Response} but that fails the HTTP request and ${x.content} returns successful but includes Tags, response and the fields within 1.
Is there something simple we've missed using composer to access what we're after or do we need to change the way our endpoint is responding 2? Unfortunately the MS documentation for FrwrkComp is lacking to say the very least.
n.b. The response is currently set up as a (syntactically) SSML response, this is just a test case using an existing resource.
Response in the Emulator
Snippet from FwrkComp
Turns out it was the first thing I tried just syntactically correct. For the case of the code given it was as simple as:
${dialog.api_response.content[0].Response}
Related
If I understand correctly, a preflight OPTIONS request is sent as a way of asking "what's allowed here?". Then, once the response comes, if allowed, the calling site sends the POST request (or GET but in my case it's a post). I have figured out that, at least with Azure Function Apps, the OPTIONS request is executing the code that I expected only the POST to execute. I believe this to be the case because once I added some null checking (since the OPTIONS request doesn't have a payload in the body) everything worked fine.
I'm wondering if this is standard.
Seems to me that if I had written the API without using Azure Function Apps, I'd have the OPTIONS request sent down a path that would set the appropriate headers and return a 200 response. And the POST request would be sent down a different path that would expect a payload in the body. If that's how it usually works then that means I've just found an idiosyncrasy of the Azure functionality. But if not it means that I have something to learn about the OPTIONS preflight request.
Thanks in advance for your advice.
Denise
As sideshowbarker mentioned, the OPTIONS request is sent automatically by the browser to check if the cross-origin request can be made.
In case of Azure Functions, this will handled by the Azure when running in the cloud.
If your function is being triggered, that would mean that you have "options" as a supported method for your HTTP Trigger
In the HTTPTrigger attribute for C# functions
In functions.json for non-C# functions
If you want to customize the CORS responses and/or running functions in a container, you could always include "options" as supported and respond differently when the incoming HTTP method is OPTIONS.
Also, if you are using Azure API Management with Azure Functions, you could offload CORS handling to it instead or even use Functions Proxies as shown here.
Thanks y'all! Sorry I was unclear. And sorry it took me a while to get back. Things have been a bit crazy on this end.
Yes, the function being called is mine. And now I understand the browser doesn't have much choice as to whether or not it makes the OPTIONS call.
And yes, I could make my Azure function handle an options call differently and thanks for that suggestion too. That's sort of what I ended up doing but basically I did it by handling an empty payload. I didn't follow that best practice originally because I thought any valid request would have a payload. Accordingly, any request that did not have a payload was invalid and should be turned away as a failure of some sort. This was before I knew that the OPTIONS call was actually executing that function.
My remaining question is if I had NOT been using Azure... if I had rolled my own solution and hosted it somewhere, I'd have a class or at least methods that handle calls to this particular API. (This is something I'm new to so bear with me if my terms aren't quite right and please do correct me). So if I'd done my own API, I'd have one method to handle a POST call and a different method to handle an OPTIONS call, wouldn't I? And the method that handles the OPTIONS call would return information about what's legally do-able with this API. And the method that handles a POST call would handle the payload sent with it. And the method that handles the POST wouldn't get executed when an OPTIONS request is sent. At least that's how I figured it would work. And that's my question -- is that how it's done when not letting something like Azure handle some of the infrastructure?
I'm just trying to learn if the OPTIONS request executing a POST's function is a standard practice or if it's some kind of idiosyncrasy to working with Azure functions.
Thanks again for the advice and for helping me understand these questions.
I'm currently using a framework in Node.js ( the botbuilder module from Microsoft Bot Framework) which uses the request[2] module to make HTTP requests.
I'm encountering a problem : this framework seems to send a malformed JSON to Microsoft's servers, but I fail to see why and what is this JSON message made of.
So I'm looking for a way to log those messages, to take a peek at this malformed JSON, as I don't have access to the request object (unless I heavily alter the framework code, which is not something one shall do)
So far, I'm able to log the response body (by adding request to the NODE_DEBUG environment variable), but not the original request body. I did try a tcpdump on our server but since it's all HTTPS there's nothing I can use there.
Any idea / tool that might help ?
Thanks for your time.
Use Node.js middleware to log all your requests. For example, you could use the module request-debug.
Another popular request logging middleware worth knowing about is Morgan, from the Express.js server team.
Is it possible to validate if an HTTP request originated from the client as GET, but was intercepted in between and converted to POST, or vice versa?
It is one of the security validations that is required as part of the project I am working on, but not getting enough clue about it. One of the way we thought of using as validation is to check if it is a GET request with a body than it could be POST. But that is just one case. Also if a POST is changed to GET by forging the request, I believe the data in the body can also be removed.
edit: Added more information about application and the intercepter
It is a regular Java web application developed using Struts with JSPs on the client side. The request from the web pages are being intercepted using Burp Suit Proxy to change the payload in the request.
Good day,
I'm having trouble calling DSAPI methods via SOAP ( C# Integration ). I keep getting 405 Method not allowed errors. So far I've tried calling the RequestTemplate and CreateEnvelopeFromTemplates methods, both of which fail. I was able to successfully retrieve the DSAPIServiceSoapClient object and also successfully login via the login method of the credential API. If you need more information, i'm ready to provide them. Thank you.
You're succeeding with the login, which is good.
My guess is that the other calls are not well formed. Perhaps they're missing the right base url (which you receive from the login call).
Are you switching to the different base url for your subsequent calls? (Different server name?)
I suggest that you try the API logging feature and see what it reports. It enables you to see a log of your API requests. See the Request Logging article for the classic DocuSign experience, or the new DocuSign UI.
i just needed to add the in the X-DocuSign-Authentication http header whenever i try to get a DSAPIClient object.
So I have a REST service setup with Jersey.
My POJO is simply annotated as #XmlRootElement
I send a POST request to my REST service and everything works fine.
1- I send malformed XML to the service I get back the containers default 400 Bad Request page. Using Glassfish 3 I can't remember exactly but I know I can change or tell my web app to map to my own 400 bad request right? Where can I look for docs on that specific subject.
2- I send valid XML but in one of the expected fields I put empty value. My service tries to do something and it throws a persistence exception. I get back the containers default 500 Internal Server Error page and it list the exception thrown. I guess I can map to my own custom error page as well, but I do not just want to show the exception message. This is considered a security issue.
I would basically like to validate the fields myself based on my business logic and return back to the client an error message such as "Field1 is invalid" Nothing more nothing less. And the client should be able to parse the error code and also know which field was wrong.
Also what can I do when my service has more then one type of bad request error? For instance, the field can expect an INT value between 1-3, but specific business request expects value of 2 and a 3 is sent.
So for type/value validation I want to simply say "Invalid field name here". But for specific business logic say for instance "Invalid account" or "Account Expired" or "Address Does Not Match" etc...
Or how about when I have more then 1 success code?
Basically I'm taking an old "xml" type service and converting to REST style for proof of concept and bring it up to standards. The old one pretty much is 100% POST even when "querying for results. I.e: GET. So basically you POST to it XML, it reads the XML, calls the business logic and logic returns appropriate code in the XML response. So everything is HTTP 200 OK and the business logic code is returned in an XML response. So the only time a client gets a 500 error is when there is hard failure where the service can't produce an XML response. Even invalid XML is returned as 200 OK, but the XML response back indicates this with my own errors codes.
A while back I was suggested I use SOAP for more "message" oriented services, but I still think it's to heavy and I can achieve with REST what my service does, even though I don't need most of REST?
You can map exceptions to HTTP responses using ExceptionMappers - see:
http://jersey.java.net/nonav/documentation/1.11/jax-rs.html#d4e433
http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/ext/ExceptionMapper.html
If you want to do validation before the request even reaches the resource method, you can try writing a ContainerRequestFilter for that and throw a WebApplicationException which takes Response as a parameter - jersey automatically maps that exception to the response it was initialized with.