I'm developing on a shared local server with some other people. This server has one Apache/PHP instance, but then it has multiple "sites-available" (VirtualHost) for different people.
I would like to get XDebug working so every one of us can use it independently. The problem is that if we enable XDebug and, for example, my IDE is connected to the server and I set a breakpoint, it'll stop if other person is browsing the page, even if it's in his/her own VirtualHost.
Any hints on how to properly set this up?
Edit:
Forgot to mention that the webserver is running in Docker.
This is the current configuration of XDebug:
# automatically start debugger on every request
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_port=9000
# send all debug requests to 127.0.0.1
xdebug.remote_connect_back=0
xdebug.remote_host=host.docker.internal
#log all xdebug requests to see is it working correctly
xdebug.remote_log=/var/log/debug.log
Thanks.
This should not happen at all, unless you have xdebug.remote_autostart turned on, and have hard coded xdebug.remote_host (instead of using xdebug.remote_connect_back). You don't want to hard code xdebug.remote_host in a multi-user environment really.
Debugging sessions are only initialised when the XDEBUG_SESSION_START is detected (which is what the browser extension will set, or when that is added to the GET/POST parameters)--and continued requests.
There is also no such concept as:
my IDE is connected to the server
Upon every request, Xdebug (if set to trigger with the cookie) will connect to the IDE. And it uses the xdebug.remote_host setting, or the inferred IP address if xdebug.remote_connect_back is enabled to connect to. And the end of the request, that connection is severed. You can use xdebug.remote_log=/tmp/xdebug.log to create a log file, which will indicate when connections are being made, and whether they work.
Related
I'm on a Mac and I've installed the latest version of the App Engine PHP SDK (1.9.19 - 2015-04-13) which include support for XDebug (since 1.9.18).
I'm using the latest version of PHPStorm (8.0.3) with the GAE plugin.
I've no trouble to run my app through PHPStorm but I can't get the debugger working automatically (will explain what it means few lines below).
Each time I try to debug my app, the debugger pane stays saying "Waiting for incoming connection with ide key '11634' " (the ide key is always a random number).
No breakpoints are triggered, and when I stop the execution, a little red popup displays: "debug connection with xdebug was not established"...
I've tried what the Google documentation suggests and it didn't work either.
Finally after hours of trying almost anything (compiling my own version of XDebug, checking every conf file, overriding php.ini to ensure paths to XDebug is correct and XDebug is on, etc...) I found a "workaround"...
The only way I can't get the debugger to work is to launch the app, then go to the debugger pane to know what's the key it's waiting for (let's say "15981"), then go to my web browser and manually add XDEBUG_SESSION_START=15981 as parameter to the URL.
Since the key changed every run, it's really a pain to work like that, and I don't talk about page redirection, etc...
Is anyone having a thought on that?
Thanks
You can start local App Endine server with App Engine For PHP run configuration, just as in JetBrains tutorial.
Then please enable Listen to incoming connections (that phone with small bug on toolbar near run configurations, or in menu Run | Start Listening for PHP Debug Connections). Then reload the page in browser. Debugger should stop on the first breakpoint or on the first line of code if that setting is enabled.
Also feel free to watch or vote the issue on bugtracker.
#leneshka has the answer! I've been pulling my hair out trying to figure out how to get PHPStorm to use the xdebug.idekey value I specified in xdebug.ini.
As soon as I enabled Start Listening for PHP Debug Connections, I was able to start debugging with my personal xdebug.idekey value.
It's easy to change the port of the application using the launcher. Go to Edit>>Application Settings (or alternatively Ctrl+i) and change the port. Since I was getting an error similar to the one given below, I changed the application port from 8080 to 48080. Unfortunately, I am not able to change the admin port from 8000 to 48000, because of which I am getting the following error.
google.appengine.tools.devappserver2.wsgi_server.BindError: Unable to bind localhost:8000
I also tried the method illustrated in the following image (my reference being this link):
Regardless of what I try, my web-browsers (Chrome and Firefox) return a message similar to This webpage is not available. Any ideas are appreciated.
I have seen this before, when I had a crashed instance running on the port. You may have a frozen Python script running on that port. On a Mac, I can go to Activity Monitor and kill the process. Not sure if you can do that via task manager in Windows. You may need to restart machine.
I'm quite positive this is an xdebug issue and not a PHPStorm issue but to be clear up front I am using PHPStorm locally to debug PHP code residing on a remote server. I have xdebug set up on the server and am using the following config in php.ini on the server:
zend_extension=/home/httpd/php_extensions/xdebug-2.1.4/modules/xdebug.so
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.remote_connect_back=1
xdebug.idekey=PHPSTORM-XDEBUG
I have set up PHPStorm as my local debugger. I use XDebug Helper in Chrome or easy Xdebug in Firefox to initialize xdebug (my problem occurs regardless of which I use). In general, debugging works fine. I can set breakpoints, step through code, see variables, etc.
The problem comes when certain requests never receive a response from the server. The server just never responds and I've validated this with Charles Web Debugging Proxy. This always happens on the same specific requests and happens regardless of whether breakpoints are set or not. The requests that don't receive a response are all similar--they call a php script which minifies and concatenates multiple JavaScript files and echos the result.
To troubleshoot, I've enabled xdebug logging by adding this to php.ini:
xdebug.remote_log=/home/httpd/xdebug.log
When I grep the log for the name of the php file being hit as the endpoint for these problematic requests I get 0 results (unless I've explicitly added breakpoints to that endpoint). When I do add breakpoints to that endpoint (minify.php) I can step through it in PHPStorm just fine and it seems to make it through the code even through echoing out the minified and concatenated JS code--yet the response is still never sent from the server as far as my local machine is aware.
Any idea what's going on here? It's really hampering my ability to use xdebug. Thanks.
It's likely that cookies don't propagate to those requests. I would suggest to see whether you can set xdebug.remote_autostart and whether it then tries to connect?
Thanks for the response. That wasn't the problem but it led me to dig further. It turns out to be a bug where xdebug crashes when php calls exit(). Using the latest release candidate fixed the problem as specified here:
http://bugs.xdebug.org/view.php?id=815
Thanks!
Using the windows host file located in
windows/system32/drivers/etc/host
Is it possible to respond a request from an application like when it is offline(not connected to the Internet)? Could you please give an example of this is done.
The hosts file only lists aliases for ip-addresses. For example:
192.168.0.1 foo bar foo.com bar.com
If that line is in the hosts file, then you can use the host-names foo, bar, foo.com and bar.com to reach the computer with ip-address 192.168.0.1.
If the computer, or the service you want to reach on that address, is not online, you can't reach it no matter what you have in your hosts file.
If you are willing to map your local development environment to a domain name, you can edit the domain name in hosts file and map it to 127.0.0.1, which is the loopback address.
That way, any requests done to that particular domain will fallback to your local machine.
You can also assign different LAN/WAN IP addresses.
When your development phase is done, you can remove the entry.
I would not recommend doing so, stick with the localhost and just make use of that to test virtualhosts setup or some sort of domain based configurations.
If there is anything else I can answer, please don't hesitate to post further comments on my answer.
If you mean to respond to HTTP requests then you need a Web Server configured to respond to any host (or that specific host name) on port 80. If you are not using it for anything else IIS can do this1 – configure it to return 404 (not found) or some other relatively neutral fail response.
1 If IIS is already being used then things get much harder, later versions of IIS are more flexible either with a combination of using HTTP.SYS to allow other applications to respond to certain URLs or using different Web Sites in IIS (until Windows 7, or maybe Vista, only available on Server editions of Windows).
I followed the installation guide for an Apache Web Policy Agent, but it always results in an endless redirect loop between web and application server. Firefox says "The page isn't redirecting properly" and Chrome thinks that "This webpage has a redirect loop". The setup is an Apache 2 on port 80 with a small demo app and a Web Policy Agent, and a Tomcat 7 server on port 8080 with an OpenAM server (the former OpenSSO from Sun):
App URL http://hostname.example.com:80/ (App and Agent, running on Apache 2.2.16)
OpenAM Server URL http://hostname.example.com:8080/openam (running on Tomcat 7.0.12)
The Live HTTP Header Firefox plugin shows that the policy agent and the OpenAM server (i.e. the Apache and Tomcat servers) redirect to each other, although the server sets the SSO Token Cookie correctly. The name of the SSO Token Cookie has the default value "iPlanetDirectoryPro". Any idea how to solve the problem?
After a whole week I finally figured it out, with the help of Stackoverflow and the OpenAM Mailing list. There were two main problems: missing log files and missing cookie domains. Installing the OpenAM server and the Web Policy Agent is difficult, there are a lot of log files and many different configuration options. If you select the wrong options, it won't work. It is impossible to make it work without knowing what is going on, which can only be determined by a suitable log file.
Missing Log for Web Policy Agent : The log level must be set in the "Java properties" files. There are two "Java Properties" files for the Web Policy Agent, OpenSSOAgentBootstrap.properties and OpenSSOAgentConfiguration.properties. The log and debug level which is named com.sun.identity.agents.config.debug.level can and must be defined in both (!) files, and it should be set to the high level, all:4 or all:5. The format is important. Even if you do this, the AgentConfiguration.properties file is only used when the agent is not working in centralized config mode. The profile must be set to "local".
Missing Cookie Domain: Do not forget to enter the right Cookie Domain during the setup of the OpenAM server in the beginning, or add it afterwards if it is missing. On the OpenAM server, go to Configuration > System > Platform and change the Cookie Domain Value to your domain (for instace .example.com) if it is missing. Otherwise the browser will lose your cookie during the redirect process. Somehow I had an empty entry for the cookie domain at the OpenAM server, I guess a forgot a dot (example.com instead of .example.com) so that it was invalid (or something like that).
This troubleshooting site was helpful to locate the problem.
#0x4a6f4672, Your post was absolutely helpful . Some more to add to your answer. The following changes is what i had to do in the config to make it running, at-least getting it running it for alfresco.
com.sun.identity.agents.config.user.mapping.mode=USER_ID(Dont use HTTP_HEADER)
com.sun.identity.agents.config.user.attribute.name=uid
com.sun.identity.agents.config.user.principal=true(Dont use false)
com.sun.identity.agents.config.user.token=SsoUserHeader(Keep it as per what is specified in you application- in my case alfresco)
Now you are not running the Agent in centralised mode but in local mode the setting which is specified for profile attribute can be only set via property file so add the following.
com.sun.identity.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid]=SsoUserHeader(whatever you want the header to come in browser as)
As told by 0x4a6f4672, it is difficult to debug and unless you are in local mode , so switch to local mode immediately and start tracing the logs and make the property changes accordingly.