I have successfully set everything up but unfortunately my GraphQL endpoint is not at the same location as the website that serves the client side.
I know this because in the error console of the browser it says :
http://localhost:3000/graphql Failed to load resource: the server responded with a status of 404 (Not Found)
three times then give up.
The page that I am using Relay is indeed at http://localhost:3000/ but my GraphQL endpoint is at http://localhost:5000/graphql. Looks like it uses the current URL then automatically append /graphql to it. How can I instruct Relay to get data from other place?
Ok, I found it. (https://facebook.github.io/relay/docs/guides-network-layer.html)
Relay.injectNetworkLayer(
new Relay.DefaultNetworkLayer('http://example.com/graphql')
);
And just in case you are running this on localhost it is still subjected to CORS because it is on different port. In my case I am using an Express server for GraphQL endpoint so I used cors middleware to whitelist my other page.
Related
We are using Traefik v2.4.7 on Docker Swarm provider. We are also using custom error middleware which routes the request to nginx server (error-pages#docker service). We have the following code in traefik.yml:
http:
middlewares:
error-pages:
errors:
status:
- "400-599"
service: error-pages#docker
query: "/{status}.html"
entrypoints:
web-secure:
address: ":443"
http:
middlewares:
- error-pages#file
Our application, which is deployed behind Traefik, has some IPs whitelisted with ipwhitelist.sourcerange=... label. If it is accessed from an IP which is not allowed, error-pages middleware routes the request to /403.html in nginx service. This is expected behavior.
However, we have some cases where our application purposely returns 403 HTTP status code and displays its own "forbidden" page with support contact form, debug information and other useful info. We don't want Traefik middleware to route the request to nginx.
Is it possible to distinguish between HTTP error codes generated by Traefik and services themselves? If the error code is generated by Traefik, then it should go through error-pages middleware. If the error code is generated by service, the page should be returned as-is, without going through middleware. How can we achieve this?
Hmm I don't think that is possible (using the built in errorpages middleware) ...
The only solution I can think of is to have the client application send back a 200 (Status Code) to every request but show the 403 (Html) page.
Use a custom plugin (middleware) eg. https://github.com/pierre-verhaeghe/traefik-replace-response-code to change the status code eg return 493 from your application and change it to 403 before it goes to the client.
Both solutions don't look good to me as the application behavior needs to be changed ... but maybe its good enough for your needs.
From the Electron renderer, I am accessing a local GraphQL endpoint served by a Django instance on my computer, which I'd like to do over HTTP, not HTTPS. But Electron's Chromium seems to intercept my fetch request and preemptively return a 307 redirect.
So if my fetch request is POST to http://local.myapp.com:3000/v1/graphql, then Chromium returns a 307 and forces a redirect to https://local.myapp.com:3000/v1/graphql, which fails because my server is listening on port 3000 and for my use case I can't do a local cert for local.myapp.com.
Theoretically the first insecure request should be hitting an nginx docker container listening on port 3000 without any SSL requirement. And nginx is proxying the request to a Hasura container. But I'm not even seeing the requests in the nginx access logs, so I'm pretty sure the request is being intercepted by Chromium.
I believe this StackOverflow comment summarizes well why this is happening: https://stackoverflow.com/a/34213531
Although I don't recall ever returning a Strict-Transport-Security header from my GraphQL endpoint or Django server.
I have tried the following code without success to turn off this Chromium behavior within my Electron app:
import { app, } from 'electron'
app.commandLine.appendSwitch('ignore-certificate-errors',)
app.commandLine.appendSwitch('allow-insecure-localhost', )
app.commandLine.appendSwitch('ignore-urlfetcher-cert-requests', )
app.commandLine.appendSwitch('allow-running-insecure-content', )
I have also tried setting the fetch options to include {redirect: 'manual'} and {redirect: 'error'}. I can prevent the redirect but that doesn't do me any good because I need to make a successful request to the endpoint to get my data.
I tried replacing the native fetch with electron-fetch (link) and cross-fetch (link) but there seems to be no change in behavior when I swap either of those out.
Edit: Also, making the request to my GraphQL outside of Electron with the exact same header and body info works fine (via Insomnia).
So I have a couple of questions:
Is there a way to programmatically view/clear the list of HSTS domains that is being used by Chromium within Electron?
Is there a better way to accomplish what I'm trying to do?
I think the issue might be from the server, most servers don't allow HTTP in any possible way, they'll drop the data transfer and redirect you to HTTPS and there's a clear reason why they would do that.
Imagine you have an app that connects through HTTPS to send your API in return for some data, if someone just changed the https:// to http:// that'd mean the data will be sent un-encrypted and no matter what you do with your API key, it'll be exposed, that's why the servers don't ever allow any HTTP request, they don't accept even a single bit of data.
I could think of two solutions.
Chromium is not the reason for the redirect, our Django instance might be configured as production or with HTTPS listeners.
Nginx might be the one who's doing the redirecting (having a little bit of SSL def on the configuration)
Last but not least, just generate a cert with OpenSSL (on host http://local.myapp.com:3000/) note: include the port and use that on your Django instance. You can trust the certificate so that it could work everywhere on your computer.
When I send the data to PHP, the browser responds with an error:
Failed to load http://localhost/api/notification/create.php: Response for preflight does not have HTTP ok status.
Here is my code to send the data
This looks like a problem with your CORS implementation. Specifically, you seem to be missing the Http method "options".
You can resolve this by either by:
Implementing CORS correctly in your PHP code. You should prefer this way if your production setup requires you to have the PHP code running on a different domain
or by using the Angular CLI Proxy. You should prefer this way if you only need the different domains (e.g. localhost:4200 for angular and localhost(:80) for PHP)
In my Grails app (2.3.11), my login page sends an Ajax request to:
https://myurl/my-app/j_spring_security_check
but spring-security redirects to:
https://myurl:80/my-app/login/ajaxSuccess
This results in a timeout error (because port 80 is added on the URL).
This problem only occurs when my client accesses the application through their traffic manager(Big-IP); if they access the application directly through server IP, it works correctly.
Is there any configuration I can do in Grails to fix this problem? I'm not sure if this problem is related to the application or Big-IP.
These are my configs (Config.groovy) related to spring-security plugin:
grails.plugins.springsecurity.successHandler.defaultTargetUrl = '/login/authSucccessExtJs'
grails.plugins.springsecurity.successHandler.alwaysUseDefault = true
grails.plugins.springsecurity.failureHandler.defaultFailureUrl = '/login/authFailExtJs?login_error=1'
grails.plugins.springsecurity.password.algorithm = 'MD5'
The problem is your application is receiving http traffic because you are offloading ssl at the BIG-IP, so it returns http links to your client. There are a few potential solutions.
Configure grails to set all URLs to https, even though requests are http
Insert the header X-Forwarded-Proto: https (if grails honors this) at the BIG-IP via a local traffic policy or an iRule (you can test this from curl by inserting the header there to see if that helps)
Rewrite https to http URLs on BIG-IP in response traffic via a stream profile or an iRule. This can be very problematic with AJAX but otherwise will work, however, option 1 or 2 would be far more efficient and less maintenance.
I get the above error message in my log file sometimes, originates from actionpack-x.y.z/action_controller/request.rb.
What should I do in order to prevent a route on anything other than HTTP methods like get, put, delete ?
HTTP CONNECT requests are generally coming from proxy server or crawlers.
We can tackle the above issue by adding a filter in web server, so that those requests are denied. So it is more about tuning the web server than doing in the ruby application.
Example: http://www.webhostingtalk.com/showthread.php?t=461915