I have InfluxDB running on localhost:8086(it's default) and a go program running on a different port (as it has to, can't also run on 8086). I am trying to post data to InfluxDB using JavaScript in my go program, and I get No Access-Control-Allow-Origin response. This github issue (posted by someone using a reverse proxy) says that the problem can be gotten around by configuring a proxy mechanism, but I am not using one. Is there a way to post data to InfluxDB without getting that response? Receiving data via post requests seems like a core function of InfluxDB, but it is not working correctly.
If it's based on Apache you just have to allow your site B to access your site A (and it's set by site A) : How does Access-Control-Allow-Origin header work?. A simple htaccess can do the job :
Header set Access-Control-Allow-Origin: http://localhost
(If it's localhost that access the site A)
Related
I have an mvc app that has been deployed to our production server. It works well under IIS 8.5 using an IP and an asigned port. But the moment I try to bind it to a subdomain the app starts showing the invalid hostname error.
Tried to see if there was something off in the applicationhost.config but the binding is in the correct format. IP:Port:Binding.
The redirection also works fine, it lands on the page, but it shows the error instead of the login page.
I have deployed sites before, but not MVC apps, and bind them to subdomains and its usually a 2 step process. I dont know what im missing here.
Edit. Here is the screen of the error. Does not say a lot.
I'm not familiar with MVC or IIS, but base on my experience with other products, you very likely need to tell IIS to preserve the Host header.
Eg. https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/modifying-http-response-headers
In order to be able to modify the HTTP Location header it is necessary to preserve the original value of the HTTP host header. The outbound rewrite rule will use the preserved value when modifying the response. To preserve the original value you will store it in a temporary server variable ORIGINAL_HOST.
You should also make yourself aware about the security vulnerabilities that can result with regard to Host headers. https://techcommunity.microsoft.com/t5/iis-support-blog/host-header-vulnerability/ba-p/1031958
We were asked to remove the server header from the http response which gives details of Application gateway v2 for the GET/POST request against the URL.
I have added the rewrites rule to remove the server header in APP GW v2. For few GET/POST requests, it wont show the server headers but when we try GET request with url http://xx.com/../../../cbs?_v=15.0.36510.0&aid=test HTTP/1.1, the server header still shows up.
Any condition do we need to apply for the rewrites to remove server header.
Short Answer: This is still not supported by the product itself
Some Background
Rewrites do not work on responses generated directly from the Application Gateway.
This is currently not supported and is part of the backlog. There isn’t an ETA on this but we will be working on this limitation soon.
You can find it in limitation
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.
I'm trying to set up a webhook for Stripe and I've created a controller, according to the Stripe doc , to do it in ASP.Net MVC running in a virtual machine (maybe that changes things?). I've been testing the action in the controller to see if I can receive posts, so I'm using Postman to send my localhost posts requests which are working. But now I need to use Ngrok to give my localhost a url so that Stripe can use it. I'm running ngrok and passing in these parameters to run
ngrok http -host-header="localhost:44368" 44368
and here is what I see, everything looks ok
But now when I try and use it in Postaman
ex https://11d1ba97.ngrok.io/StripeWebHook/Index
I get a 502 Bad Gateway message and the action method never gets hit.
I get the same problem when I try and send a test webhook from Stripe.
FYI - The request times from Ngrok using 'localhost:4040' show all my response times as 0ms.
Update - I was emailed by ngrok
"The trouble is the HTTPS. ngrok terminates HTTPS traffic and then forwards the unencrypted http traffic through to your local application. You want to do one of two things:
1) make your application expose an HTTP port as well and forward traffic to that
2) use ngrok's TLS tunnels (which hand of TLS traffic to you for termination). with this option you have all the complexities of doing cert management, cert mismatches, etc, just fyi. i'd recommend #1 if possible"
Question - anyone know how to open up a http port in a ASP.Net MVC app using Https?
My problem was that the breakpoint in my application wasn't getting hit.
I was using
ngrok http 58533
but changing it to the following allowed my breakpoint to get hit.
ngrok http -host-header=rewrite localhost:58533
Bit late to the party :)
I could get http working by un-checking Enable SSL flag in Properties.
Step 1: Right click Web Api project, select Properties
Step 2: Download and install extension
https://marketplace.visualstudio.com/items?itemName=DavidProthero.NgrokExtensions
Step 3: Start ngrok Tunnel from Visual Studio
(image from https://raw.githubusercontent.com/dprothero/NgrokExtensions/master/docs/img/menu-item.png)
Step 4: Copy Forwarding http url
Step 5: Paste in Postman, and append the controller/action
you get 200! (upvotes? :))
I have a swagger working with a haproxy. I use built in swagger in Websphere Liberty Profile (apiDiscovery feature):
Browser -swagger.mydomain.com-> haproxy -swagger.intranet-> IBM Liberty server with Swagger
The first swagger page is generated and shown correctly in the browser, but as Liberty server gets the request from haproxy, not my browser, and gets them to the intranet name/ip (swagger.intranet), Swagger code to execute GETs, POSTs, etc. is generated with that intranet IP name (swagger.intranet), so when I try any of the methods they won't work as reference this internal ip name from in a browser outside that zone.
Can I configure haproxy with some header to inform haproxy that he should generate code with the original server name (swagger.mydomain.com) request used in the request? (That is the one to be used in the generated HTML/Javascript code)
Thanks.
Liberty trusts the Host: header and uses it to assemble self-referential links.
Where you define the backend, try setting http-request set-header Host swagger.mydomain.com to what the client will be using or removing a similar stanza if you are setting it to some swagger.intranet already.
(sorry, I'm not an HAProxy user. This is based on searching for 'HAProxy equivalent of ProxyPreserveHost')