I jus installed Solr 4.2 on my local computer using port 8080 and test ok with url http://localhost : 8080/solr/, then I share this to my colleagues with url http://10.18.59.179:8080/solr/ where 10.18.59.179 is local ip of my company. However my colleague (his ip is 10.18.59.105) told me, the admin main page just shows 'loading...' and hang there. I've installed solr 3.3 before and they can connect to admin page on my computer correctly. What's wrong with Solr 4.2's admin page?
Solr 4.2 code is a tested and working stable release. If you can reach its admin page but someone else can not reach it, the first thing to check it does another machine has right to reach your computer.
In my case, any browser will show 'loading...' forever. The reason, again in my case, is I started Solr 5.2 with a typo in ZooKeeper switch. It should be "-z localhost:2181,localhost:2182,localhost:2183" but I had "-z localhost:2181,localhost2182,localhost:2183". After adding the ":", everything started working again.
Related
I started a tutorial regarding AnguarJS for beginners. I have setup my workstation already and ready to test a simple Hello World. Unfortunately, I cannot display this simple message in my localhost. Instead, it display the default IIS image and I've noticed also that my url is the current IP Address. Can anyone pinpoint what I missed here?
Please see below image for reference.
The dev server shows that it is running on port 4200:
As the message says, you need to navigate to http://localhost:4200 (instead of http://localhost, which it looks like is being served by IIS)
Note:
I have googled, and read these issues:
Cannot access API explorer on localhost
How to force loading dynamic, insecure content in Chrome?
and many others but they do not solve my problem.
The problem:
I'm running MacOS and doing my development int Debian VM running in Paralells.
I start up the dev server using the following command:
dev_appserver.py --clear_datastore --host 0.0.0.0 --admin_host 0.0.0.0 app
and I can access the app, endpoints, admin module etc from MacOS using my Debian machine IP eg. http://10.211.55.6:8080/_ah/api/my-service/v1/api etc... everything works fine and as expected except for Google API Explorer.
When I try to access http://10.211.55.6:8080/_ah/api/explorer I am redirected to http://apis-explorer.appspot.com/apis-explorer/?base=http:///10.211.55.6:8080/_ah/api#p/ as expected and I get the ssl error as described in the issue above (again as expected) but then I get redirected a couple of more times and end up at https://apis-explorer.appspot.com/apis-explorer/#p/
Note: I cannot click on the lock icon in the title bar because of the redirects
I've tried almost everything I can think of and have google extensively to no avail. Hope someone can help me, I suspect it has something to do with the dev server being run inside of a VM, but I am not sure.
there is a shield icon in the rightmost part of the address bar that appears when you access the api_explorer locally in chrome. Click and then select load unsafe script and it will load all the service endpoints you define.loading api_explorer locally
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.
I have a CakePHP website that's been working great.
I just developed a new functionality that at one point auto-logs the user in, and redirects him to a page that's behind the login wall.
This works perfectly well in my dev machine, but in production, the user gets redirected to the login page.
Relevant code: (not much)
$objCustomer = $this->Customer->findById($customerId);
$this->Auth->login($objCustomer);
$this->redirect("/customers/signup");
Customer is the Model that's used for authentication.
In the server, I see that I AM getting redirected to /customers/signup, and that redirects me to /customers/login
The thing that confuses me the most is that this works perfectly in my machine.
I dumped the return value of Auth->Login in the server, and it returns 1, so in theory everything is fine and the user should've been logged in.
Some things I can think of that are different between my machine and the server:
Dev machine is Windows, Server is Linux. This sometimes introduces case-sensitivity issues, but the signup method i'm redirecting to is all lowercase, I don't see where there could be such a problem here.
Dev machine is IIS, Server is LiteSpeed. Maybe Litespeed is screwing with something? This would be the first time in over a year running this site in production that i'd find something different because of LiteSpeed
Production site is over SSL, dev is not. I don't see how this could be a problem.
Any ideas are infinitely welcome!
Thank you!
I had problems too with authentication working fine on my machine in development mode, but not working on the server in production mode. Surprisingly, when I changed the server to development mode it started working correctly. Then I changed back to production, and it was still working. Perhaps it was some cache issue.
After a LOOOONG process of trying different weird things, it turns out it all boils down to this:
ini_set('session.referer_check', $this->host);
That's part of CakePHP's standard security features... It sets that INI setting.
If the request made to the action that'll call Auth->login is coming from another host (domain/subdomain/whatever), PHP will consider the session invalid, which effectively kills the auto-login attempt.
Im really having a problem with this one. My server is a linux CentOS based running Plesk 9.2
After the update my email forwarding stopped working! Plesk uses qmail to manage emails. Basically whatever I do in the webpased Plesk panel just does not work with email forwarding. Does anyone know what can be the problem and how can I fix it?
I wish, haveing a similar problem but with and older version of plesk. After I rebuilt the qmail queue email redirection stoped working. Strange because everything looks fin in the psa mail log