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.
Related
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}
I have written a web server in nodejs. Most of the time I am receiving a message from one service, doing something, and sending a message to another service. I am in the middle of all the communication.
Sometimes, the communication fails. I am trying to debug what's going on. I would like to examine the request that comes in.
I have a node service, written in express. I have routes, and the routes are passed a req object and a resp object. I should be able to just print out the req object. Problem solved!
But JSON.stringify throws an error. util.inspect doesn't throw an error, but many property values are marked [circular]. The actual property value isn't shown.
When I console.log(req.body) it prints undefined. When I look at req.body using util.inspect, it prints body: {}
I have the feeling the framework is hiding things from me. I don't know how to get the information without it being prettified.
At the tcp/ip level, it's too detailed. At the application level, it's not detailed enough. But at the http level, it should be just right. The request that is received is just text. I should be able to print it out.
I tried using Charles, but I'm having trouble configuring it.
Surely, other people have wanted to see the request as it comes in, before the framework massaged it. How did they do it?
you can use morgan module, it's a HTTP request logger middleware for node.js
I made a more specific question, using a lower level of the node stack of middleware. I got an answer there:
Where did the information I passed in go?
Here is the discussion of how node came to be designed this way:
Node.js - get raw request body using Express
Basically, there used to be a rawBody attribute of the request object in node. People took it out. To accomplish the same thing requires a little bit of code.
I am totally new to Action HeroJS and I was wondering how can I restricted users to access my action herojs rest API, url from the browser?
I have even put the route as POST, but it is still accessible by get method?
Just like in java when we specify a rest api as post, it will not be accessible by get or browser url?
How can I accomplish this?
Edit:
Contacted the Action Hero, on github, they were pretty helpful, the solution was:
in web.js, put simpleRouting : false, and it should resolve the Issue.
Before you could access a post routed action, from the URL but after doing this you cannot!!
accessing a POST using get will return you a 404.
Thanks #Evan
Regardless of your language/framework, all routes are able to be hit by anyone, unless you block them at load-balancer or similar level.
Rather than thinking about the problem as "how to block" access, you should be thinking about the problem like "how can I ensure that this user is authenticated to use this route". Using things like cookies or tokens is the way to go.
You can use actionhero's middleware to apply access rules to specific actions, and return errors to the use if they aren't allowed.
Here's an example project that does these types of things:
Actions for dealing with the session: https://github.com/evantahler/actionhero-angular-bootstrap-cors-csrf/blob/master/actions/session.js
Middleware which uses that session data for access: https://github.com/evantahler/actionhero-angular-bootstrap-cors-csrf/blob/master/initializers/session.js
and finally another action (route/url) which requires the logged-in-session middleware: https://github.com/evantahler/actionhero-angular-bootstrap-cors-csrf/blob/master/actions/showDocumentation.js
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.
Due to some limitations about the web services I am proxying, I have to inject some JS code so that it allows the iframe to access the parent window and perform some actions.
I have built a proxy system with node-http-proxy which works pretty nicely. However I have spent unmeasurable hours trying to modify the content (on my own, using harmon as well, etc) that is being sent to the user without any success. I have found some articles and even some questions here but all of them are outdated and are not useful anymore.
I was wondering if someone can give me an actual example about how to do this, because I am unable to do it and maybe it is just that it is impossible to do at this point?
I haven't tried harmon, but I did try cheerio and it works.
However, I used http-mitm-proxy and not node-http-proxy.
If you are using http-mitm-proxy, you need to return a promise in the response handler. Otherwise, the proxy continues to send the original response without picking up your changes.
I have recently written another proxy at:
https://github.com/noeltimothy/noelsproxy
I'm going to add response handling to this soon. This one uses a callback mechanism, which means it wont return the response until the caller signals it to.
You should be able to use 'cheerio' and alter the content in JQuery style.