I am unable to connect to my Apollo (graphql) server through Apollo Studio (https://studio.apollographql.com/sandbox/explorer) OR Apollo Client library on frontend. But the server is working fine when a request is sent through Postman, graphql-request library OR a CURL request.
Details of Deployment:
The server is deployed on GCP instance groups which include 4 instances in two different regions. I have used Nginx as reverse proxy to redirect traffic to localhost:4000 of each instance (the app is running on port 4000 of each machine).
The instance groups are attached to the GCP HTTPS load balancer. The backends are in the healthy state in the load balancer.
Apollo studio - not working
Postman - working
If it's working in postman but not in studio, it's generally either an issue with CORS, some other header issue, or something similar to that.
Studio is running in a browser, so things will be a big more finicky. It will send headers that browsers always send, like the origin it's running on, and those that Apollo decides are best, like certain accept / content-type headers that your load balancer might not be allowing through.
Things like Postman and cURL generally come with less "baggage". They only send the headers and content you ask them to.
The best thing to check next is what your browser thinks is going wrong, since servers won't "lie" about the problem unless you specifically tell it to (e.g. for security reasons, some information is sometimes best left out). Open up your browser debugger on the Studio website when you try to make a request and check your Network panel. The HTTP call will fail in a certain way if it's one of these issues, and it should be pretty straight-forward with you that it was rejected because of X.
Related
Most articles or answers I find deal with proxying a localhost url to a localhost backend server on a different port, or to a non-authenticated remote server (no log in required). However, what I am unable to find is how to generically proxy requests to a remote server that requires authentication.
A common practice in web development is to create multiple instances of the app (beta/dev, integration/test, production, etc.) so you can test and deploy gradually before the code hits production. Each instances has it's own backend server and data that is typically accessible through public urls (e.g. beta.app.com/api).
The difficulty comes when the api requires user authentication to access. Setting up a typical proxy won't work as the credentials from localhost will be different from those of the remote server.
What I want to be able to do is be able to proxy all localhost api calls to one of the remote servers so I don't have to run a backend server locally, or be able to test local code against remote data (great for debugging prod only bugs). What I don't want to have to do is hardcode credentials to the remote server into the proxy, as that won't work for anyone else who runs the app locally (so no hardcoding proxy headers that add auth cookies, etc.).
I image the solution will require more than just a proxy to work, and that's fine. Assume I have full control of both the frontend and backend and can make any changes needed to make this work.
I am creating an application, while working on its back-end I found that anyone can see my data while connected to server. I want to secure them. I tried many application which blocked the proxy connection like gmail and other big applications while I used them by turning on fiddler proxy they stopped me to connect to server by saying please remove proxy but when I used my application data via fiddler it showed all my data.
How can I check this?
You haven't specified what "applications" you're referring to (e.g. web pages vs. native apps on Android, etc), but in general you cannot detect Fiddler nor should you bother to try, as anything you do can be undone by a motivated attacker.
More of a theoretical question, but I'm really curious!
I have a two part application:
Apache server hosting my UI
Back-end that services all http requests from the UI
The apache service proxies all http requests from the UI to the server. So, if the user is reasonably adept, they can reverse engineer our API by inspecting the calls in the browser's developer tools.
Thus, how do I prevent a user from using the server API directly and instead force them to use the UI?
The server can't determine whether a call came from the UI or not because a user can make a call to myapp.com/apache-proxy/blah/blah/blah from outside of the UI, apache will get the request and forward it to the server, which will have no idea it's not coming from a UI.
The option I see is to inject a header into the request from the UI, that indicates the origin of the request as the UI. This seems ripe for exploitation though.
To me, this is more of a networking question since its something I'd resolve at the network level. If you run your backend application in a private network (or on a public network with firewall rules) you can configure the backend host to only accept communication from your Apache server.
That way the end-user can't connect directly to the API, since its not accessible to the public. Only the allowed Apache server will be able to communicate with the backend API. That way the Apache server acts as an intermediary between the end-user (client side) and the backend API server.
An example diagram from AWS.
You could make the backend server require connections to be authenticated before accepting any requests from them. Then make it so only the Apache server can successfully authenticate in a way that end users cannot replicate. For example, by using SSL/TLS between Apache and the backend, where the backend requires client certificates to be used, and then issue Apache a private certificate that the backend will accept. Then end users will not be able to authenticate with the backend directly.
I'm trying to build a complete web caching proxy using Boost Asio and LibCURL, I've already built the server and everything works fine. It receives http requests (GET, POST, upload using POST ...) correctly and also it sends back the responses to the browser for e.g correctly.
Now, I want to extend it, so it can handles https requests. I read about it in LibCURL web site http://curl.haxx.se/libcurl/c/libcurl-tutorial.html (proxy section), I understood how it works and I have a clear idea how it should be done. But I didn't find a good documentation about how proxies handle https requests. and:
what are the possible messages (information, format, length ...) exchanged by the source application and the proxy ?
things to consider.
...
Thanks in advance :-) .
You will receive the CONNECT command in plain text, and respond to it ditto, then the communications after that will be encrypted. If your proxy is to be an SSL endpoint, which is highly problematic given that HTTPS requires a certificate that matches the target host-address, you will then need to enter SSL mode on both connections. More probably you should just start copying bytes in both directions without attempting to process the contents.
i'm having a problem using Load-Balancing on my server (using IIS 6). I have a Manager Website that works correctly most part of the time, but sometimes when i go to another page inside this manager, instead of redirecting to the correct page, it redirects to the login page of it.
I don't think this is a timeout problem, because if i press F5 it redirects to the correct page. I suppose it's a problem with the Load-Balancing, because I tried to run the Manager in another machine without Load-Balancing (still using IIS 6) and it worked fine.
I'm using ASP.NET 3.5.
Could someone figure out why this is happening?
If session information is stored locally on a web server then when a load balancer sends your request to another server (say server2) in this farm - server2 doesn't have session information about your request and it correctly sends you to the login page. When you hit F5 load balancer sends you to the original server1 which has authentication information and successfully displays the page.
You need to store session information in a central location so that all servers in the farm could see it.
One way is to store sessions in a centralized place, as already pointed by DmitryK, other way is to forward the request of one session to only one server. So that ASP.NET can found sessions for that. You can use Cookie based request forwarding or IP based request forwarding. IP based forwarding may not work in some cases, if the ip's are masked by some NAT(Network Address Translation). Please check what all options are provided by your load balancer.