We're using an Application Gateway at the moment for our application. It serves two purposes: provide an HTTPS endpoint for public access to our app, and using a Path Rule to redirect incoming requests to the appropriate backend pool based on the URL of the request. Working fine so far.
We're looking at using compression for our responses to reduce the payload being delivered back to the client. Is is possible to enable compression at the Application Gateway? So, when it receives a response, it could compress it before returning it back to the caller? We're trying to determine if we implement this in our application itself (sitting in the backend pools) or can we do this in the App Gateway.
If not, would there be any plans for this?
I'm seeing in my AG responses this header without making any special config:
Content-Encoding: gzip
So I think it is compressing. I don't know how long this has been working though.
Related
I'm currently running a windows azure web app behind an application gateway v2.
I would like to use header information for x-forwarded-host or x-original-host - but it does not work.
Now I'd like to trace what request headers are actually received by the web app. I'm trying network-capturing. But as the whole traffic is HTTPs - I guess I'm not seeing all the fields.
Any Idea?
You can configure application gateway to modify request and response headers and URL by using Rewrite HTTP headers and URL or to modify the URI path by using a path-override setting. However, unless configured to do so, all incoming requests are proxied to the backend.
For more details, you can read the offical document.
I have a Node.js express server deployed to AWS EBS, the client side, written in React is deployed to S3 bucket as a static web page.
I'm working on some sort of sign up system to a specific service, and I don't want to request credentials from the user, so I guess csrf \ jwt is not going to work.
Is there anyway to block all http requests from origins other than the client? right now, there is a chance someone will just use Postman and make requests to my server, for example creating user with just an email.
I tried using private API Gateway, but I couldn't find a way to let the client make requests successfully.
I thought about encrypting the http requests payload, but I didn't find anyway to store a private key where it is not visible for anyone through the browser...
The origin is just an HTTP header that someone could set, i.e. "spoof", in their Postman requests. You can check the origin to block random scanner bots, but it isn't going to block anyone that is determined. So please don't confuse this as actual security. You could do this with AWS Web Application Firewall attached to your EB load balancer, or just adding a check in your express middleware as in the other answer.
Regarding private API Gateway, that would never work in this scenario, that is only for resources inside a VPC network, and your React app is running in people's web browsers on the public Internet.
Regarding someone creating a user account "with just an email" that is on you to handle, you should be completely validating the request on the server side, with the knowledge that the request may have come from someone using a tool like Postman since there is no way to totally prevent that in your scenario.
If you want to use API Gateway for this you could try implementing request validation there. You could also attach a Web Application Firewall to the API Gateway. I believe you could also do the origin header check as part of an API Gateway request validator.
You cannot block all the HTTP requests but surely can reject by adding a middleware
app.use((req, res, next) => {
if(req.protocol === 'http' && req.hostname!== <client domain>){
return res.sendStatus(403);
} next();
})
Hi I have a question about azure mobile apps.
Can I confirm HTTP request including header, body and url parameter in azure mobile apps when troubleshooting?
If yes, how can I confirm that?
For example, let me assume that client send a HTTP request to azure mobile apps, and a the response is bad request(status code 400).
Then I would like to figure out the cause.
First of all I set [Diagnostics log] - [Web server logging] as Storage in portal.azure.com,and confirmed the IIS log.
But there is no header, body info in the HTTP request.
So I did not find out the cause by that log.
Finally problem is solved by client logs by taking fiddler and cause is wrong info in body of the http request.
Above all, by taking fiddler log in client side, I was able to solve the problem but I would like to know if there is a way to confirm http request's header, body and url parameter in azure mobile apps side.
You can log the inbound query on the client or server side, or use something like Fiddler. For the server side, just use regular methods for Node.js or ASP.NET - nothing special is needed. For the client side, I documented the process for all platforms on my blog. Although the documentation is for adjusting the HTTP request, it's the same recipe for logging.
We are currently working on a nodejs application which hosts API's (includes both get and post HTTP methods). These server API's in nodejs server are individually accessible or allowed to be called. Like /api/login (login api) is allowed to be called directly from clients.
Next, I want to introduce a service broker API which should be entry point to all API calls from client side. So, any client calling a specific API such as /api/login should go through service broker and then service broker should re-direct to requested API based on the specific service details as sent by clients.
Thereby, all clients should only be able to call only one API (i.e. broker service API - /broker/service). So, all requests from clients should first hit service broker API and then service broker should redirect to appropriate API's based on the input parameters passed to service broker from clients. Input parameters could contain the API URL and input data.
Currently, I'm able to connect directly to individual API's from clients. But, now I would like to introduce a new layer namely service broker and that broker service should decide which API the request should be redirected along with input data (sent from clients).
Note: Both broker service API and other functionality specific API's are hosted under same domain. So, there will not be any CORS issue. We are using "express" node module for handling HTTP API requests.
My initial question is whether this requirement can be achieved?
If yes, then can we perform internal redirection of API's in node server?
Can this be achieved with express node module?
Please help me in this regard.
If you really wanted to go this route, you could do something like this:
app.get('*', function(req, res){
the_route_passed = req.originalUrl;
//handle all of the routes here in your api function call.
});
What this will do is for every single route passed from the front-end will go through your function, and then you can grab the route that was passed req.originalUrl will be like /api/users/230 for user 230. Then you'll need to parse the route or however you want to do it and pass it through to your service broker.
This would be the best way to deal with not having to change anything on the front-end if you are already using Routing. The other way which might be better in the long run:
Send JSON on each request and configure it however you want, and then when you receive it you can figure out all the routing from the JSON request on each go. You'd have to rewrite all routes on the front-end to do this though which might be too much work.
I am currently developing an API that will be launched into production in a matter of weeks. I am relatively new to REST, started reading about CORS - and realized that it could impact me.
What conditions will a REST service not be accessible to a client? I have been using sample html/js on the same server, and through Postman - a google chrome addon - to access my API. I have had no issues so far.
When the API goes live, it will be hosted at 'api.myserver.com'. Requests, at the beginning, will come from 'app.myOTHERserver.com'. Will these requests be denied if I do not use a CORS-friendly approach like JSONP or special 'access-control' headers that permit my domain?
What about accessing rest APIs from other non-browser clients? Such as a C# application? Are these requests permitted by default?
Assuming I do need to add 'access-control' headers server-side, to permit the scenario described above when my API goes live, is it better (performance-wise) to let your web server (NGINX in my case) handle the headers, or should I add them through PHP or NodeJS?
This is more about the same-origin policy applied by web browsers than it is about RESTful APIs in general.
If your API is intended to be used by web applications deployed on a different origin host/port than the API, then you have these options:
Respond with appropriate headers that allow for techniques like CORS to work.
Have the web server which serves up your web content (in your example, app.myOTHERserver.com) handle your REST API requests too by proxifying your API requests from the web server through to the API server. For example, you could have your API exposed on your web server under the URL /api, and then it's just a matter of setting up a web proxy configuration that forwards requests under that URL to your API server.
Use JSONP or other techniques.
If your API is going to be used by non-web applications, you have nothing to worry about. This is only a restriction applied by browsers when running JavaScript code to make sure that the user hasn't inadvertently clicked on a phishing link with some hackery in it that tries to send their PayPal password to Pyongyang.
When the API goes live, it will be hosted at 'api.myserver.com'.
Requests, at the beginning, will come from 'app.myOTHERserver.com'.
Will these requests be denied if I do not use a CORS-friendly approach
like JSONP or special 'access-control' headers that permit my domain?
You can specify what clients can access your web service to an extend. Assuming you're using Express: How to allow CORS?