Have just moved old (but running on the RedHat OpenShift PaaS) node app (Meteor to be ohnest) into new Linux VPS box.
The problem is that node server seems to refuse (block,do not provide, do not service) the XHR type connections from browser directed to the port usally defined using the
DDP_DEFAULT_CONNECTION_URL
env variable.
As I understand it's used for Ajax like responsiveness build in the Meteor apps.
From the browser point of view, I just see failed XHR type connections to the DDP url.
Firewall seems to be set ok.
Http communication (port 80) works ok, so I can get the static part of the web page and even navigate to other static pages but no dynamic data /like db/.
Any idea ?
You forgot to put export before setting the environment variable.
Run this command and I hope that will solve your problem.
export DDP_DEFAULT_CONNECTION_URL
So it was just the DDP_DEFAULT_CONNECTION_URL setting. Once the app was deployed to the RH OpenShift PaaS the value used there was :8000. My fault was I assumed it has to be the same everywhere. Changing it to :8080 (port used by node) made app working.
I just thought they have to be separate ports (one for www and one for DDP).
Related
I use React-Native for an app and Spring Boot for backend. For making requests from the app, I use Axios.
I am developing a new backend service and I wanted to test it on the app before making a backend deploy. Usually, I would simply use something like axios.post('http://192.168.1.25:8080/resource'), to access the server running on my PC connected to the smartphone via LAN. It works.
This new service, however, depends on the subdomain sent with the the HTTP request. For instance, on the previous example, I would have to make a post to 'http://english.192.168.1.25:8080/resource'. Making a axios.post() to that address however, doesn't work. Axios gives me the error "can't resolve english.192.168.1.25".
Does anyone know how to solve this? Testing with Postman from another machine, the endpoint 'http://english.192.168.1.25:8080/resource' works just fine (Only the axios lib running on the react-native phone fails).
TLDR;
try to disable your dns-rebind protection in your router by adding an exception for your subdomain.localhost
FritzBox -> Home Network -> Network settings -> DNS Rebind Protection
the other way would be to run your own dns on your system which does the same. Something like dnsmasq or https://github.com/hubdotcom/marlon-tools/blob/master/tools/dnsproxy/dnsproxy.py
I think i found a solution for this problem. something.localhost is routed to your primary dns. In a typically installation its your router. Most modern routers have a dns-rebind-security mechanism. https://en.wikipedia.org/wiki/DNS_rebinding
I ran into the same issue at home and when i tried to get foo.localhost running at work, it works as expected. So what can I say. At home we use a FritzBox 7560 with DNS Rebind protection enabled. At work I have a noname router from a "magenta company" without a rebind protection.
I just configured an NGINX instance on the Jelastic platform.
In my environment's firewall inbound rules there are now a few default rules added.
With source All. (HTTP, HTTPS, ...)
I changed the source of these firewall rules to Local LAN.
So I expect that when I go to my Jelastic public URL in my browser on my own computer, I do not get a website but I'm blocked by the firewall.
This is not happening. I do not want the website to be used from the outside. This environment will host some REST API's and workers running on the inside and only triggered by other environments I have.
Kind regards.
Roel
We recommend following this guide to disable access to your container (CT) from the outside: https://docs.jelastic.com/release-notes-59/#restrict-node-access-via-shared-load-balancer-slb
However, please keep in mind that you'll not be able to access this CT from another CT too.
UPDATE:
little clarification
If "Access via SLB" disabled, the nodes within the layer are inaccessible via SLB (including the Open in Browser button in the dashboard) and return the 403 "Forbidden error" instead of the intended service. Herewith, access via the private network from the other nodes of the environment, access via SSH and access via endpoints from the public network is not affected.
We also want to draw your attention to that described feature is available from the Jelastic PaaS 5.9 release
I would like to know if anyone has a way to get the IP address of the currently used proxy IP of a running TestCafe test. I would rather not add the overhead of first loading up a site that gives me the proxy IP I'm using and instead would like it if there was some internal way to discern it.
After much work on this, I have solved this by creating an express server, installing request-IP (a node.js library which gets the requesting IP), and then basically setting up an endpoint /givemyip to ping that first before actually navigating to the target testing page. Doing so let me view every single proxy in the terminal. I then simply wrote each IP to MongoDB along with the result data from each test. Solved!
I'm building an application in Ember.js and I am debugging the PHP API remotely. It is working when I enable the cookie for XDebug, set a breakpoint, and then run the code. The breakpoint hits and I get all the debugger data in my IDE (PHPStorm) correctly.
In order to access the API from Ember, I have to use ember-cli with a proxy. The XDebug cookie is getting passed through the proxy, but requests that I make through Ember do not hit breakpoints in my IDE. I think this is due to the fact that XDebug sees the ember-cli request as coming from the remote server, rather than my development machine. Is there a way for me to get debugging to work for requests that go through the ember-cli proxy? I have to use the proxy instead of going directly to the API from the browser due to cross site browser security issue (ember-cli is running on port 4200 on the server and the API is on port 80).
I have pydbgpproxy running and PHPStorm is working with that as well, but even though the session for the requests going through ember-cli and the requests going from my machine directly to the API are the same key, I think it's still differentiating between the requesting machine's address.
Thank you!
Never mind, I realized that I needed to configure the contentSecurityPolicy in environment.js in Ember and then change my PHP API to return the 'Access-Control-Allow-Origin' header by using using nelmio/cors-bundle
I am trying to access Sonar through web browser. I already started it on my terminal but when I try to access it on web browser through , it shows nothing. However, the status shows Sonar is running. How can I make it running on the web browser ?
The configuration for Sonar web is:
sonar.web.host=127.0.0.1
sonar.web.context=/sonar
sonar.web.port=9000
sonar.web.host=127.0.0.1
I think this is the problematic line in your conf. This line indicates which IP address the Web Server will bind to. If you set it to 127.0.0.1, then Server will only respond if you reach to it through the IP 127.0.0.1, that is, you'll only be able to access it from localhost, though IPv4. (Your browser will probably prefer IPv6, with ::1 being the host)
Comment out the line (prepending a #) in order to have it listen to every IP the machine is called by.
If you can verify access from the host machine itself, but the above doesn't help, then you might want to check if your firewall is blocking requests.
With the settings you provided, make sure you're using this URL and trying to access the server from the same box: http://127.0.0.1:9000/sonar/
If you're attempting to reach http://127.0.0.1:9000/ and getting the empty page, it's due to the sonar.web.context value you're using.
Note: unless you're hosting SonarQube in an external webserver, you don't need to set the sonar.web.context, in which case, you would just go to http://127.0.0.1:9000/
If this URL isn't working for you, I would suggest looking at the SonarQube server logs in the /logs folder to determine if there were any errors starting the server. If so, you'll want to update this posting with the details from the log, including which operating system you're running.