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
Related
I've set up a proxy in package.json which points to the staging server so all API calls are routed to that server.
Works fine and gets the response from the actual server as expected, however, the responses seem to be getting cached in the proxy.
I've hit the staging site itself (which calls the same API) and i can see the updated response, but when hitting it on localhost via the the proxy I'm getting a stale version. Even when I add a cache busting querystring on the end of the URL it still gives me the old versions..
I've tried stopping the dev server (which was started from npm run start) and restarting, but it's acting like the proxy server doesn't stop/start in the background and is caching the requests.
Question is:
Is there a way to blow the proxy cache away from temp files etc? (or any interface to see what it's doing)?
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.
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).
I'm an iOS developer primarily. In building my current app, I needed a server that would have a REST API with a couple of GET requests. I spent a little time learning Ruby, and landed on using Sinatra, a simple web framework. I can run my server script, and access it from a browser at localhost:4567, with a request then being localhost:4567/hello, as an example.
Here's where I feel out of my depth. I setup an Ubuntu droplet at DigitalOcean, and felt my way around to setting up all necessary tools via command line, until I could again run my server, now on this droplet.
The problem then is that I couldn't then access my server via droplet.ip.address:4567, and a bit of research lead me to discovering I need Passenger and an Apache HTTP Server to be setup, and not with simple instructions.
I'm way in over my head here, and I don't feel comfortable. There must be a better way for me to take my small group of ruby files and run this on a server, than me doing this. But I have no idea what I'm doing.
Any help or advice would be greatly appreciated.
bit of research lead me to discovering I need Passenger and an Apache HTTP Server to be setup, and not with simple instructions.
Ignore that for now. Take baby steps first. You should be able to run your Sinatra app from the command line on the DigitalOcean droplet, and then access it via droplet.ip.address:4567. If that doesn't work something very fundamental is wrong.
When you start your app, you will see what address and port the app is listening on. Make sure it's 0.0.0.0 and 4567. If it's 127.0.0.1 or localhost that means it will only service requests originating from the same machine
After you get this working, next step is to make your Sinatra app into a service. Essentially this means the app runs in the background, and auto-starts when the system reboots. Look into Supervisor which is very simple configuration to get this running.
Later you can install Apache or Nginx to put in front of your Sinatra app. These are proxies which simply forward requests from port 80 (default HTTP port) to your sinatra app, but can do additional things such as add SSL support, load balancing, custom error pages etc. - all of which you do not need right now.
This issue is occurring in a C#, .NET 4.0 environment. I tried using Fiddler but it doesn't show up. After searching around, the suggested solution was to change the address of the request from localhost to the machine-name.
This worked on my local machine: after changing the call from localhost to my-machine, fiddler picked it up. The real issue is on a client's staging environment with production code. I can not modify the code there to take this change.
Note, as far as I know, on the client site it should be making the request out to the host name and not localhost anyways.
Also, on my local machine I actually hit localhost in my browser, and it seems to pick those up fine. Just not the request built in code. Why is that?
Thanks!
It sounds like you're saying: "This works fine on the client's PC but not on my dev PC when using Localhost." Is that correct?
In IE9, I changed WinINET to enable Fiddler to capture loopback traffic from the browser. Sadly, the .NET Framework hasn't yet adopted support for the <-loopback> token, which means that traffic sent to 127.0.0.1 or localhost bypasses the proxy.