VoiceXML script runs fine on gist.github.com but won't run on my server - vxml

I have a VoiceXML script that works fine when I call to it on gist.github.com - https://gist.githubusercontent.com/jpelton/6bb484628f3bb3ef9cd1/raw/gistfile1.txt but when I call to the exact same VoiceXML script on my own server (https://mobile-text-alerts.com/3.0/system/nexmo/recordMessage.php) the phone just rings twice and hangs up. The scripts appear to be exactly the same.
Is there some header value that is necessary that I am missing?

There was an issue where my phone provider (http://nexmo.com) was not trusting my comodo signed SSL certificate. I sent them to http://mobile-text-alerts.com/3.0/system/nexmo/recordMessage.php instead of https and it "fixed" the issue (until I get a new certificate).

Related

Is there a way to disable chrome automatically redirecting to https? My situation is a bit tricky

Lets say the name of my service is 'redyellowgreen'
my server only accepts requests from redyellowgreen.world
I am currently using a mac, and I have changed my host file using
sudo vim /private/etc/hosts
command to access localhost in local.redyellowgreen.world
untill some point last week, I was able to access local.redyellowgreen.world just fine in incognito mode in Chrome.
But for some reason, I can't now....
when I try accessing localhost:3000, it works just fine but no response from server. when I try local.redyellowgreen.world:3000, It does not work and shows 'This site can’t provide a secure connection' Error and 'ERR_SSL_PROTOCOL_ERROR' code in chrome
I tried deleting in domain in hsts, flushing dns, removing cache and many other things.
Is there way to disable this auto-redirect?

Getting a Certificate error when making a GET request in a VS Code extension webview

I'm creating a VS Code extension with a webview that contains a React application. In the React code, I'm making a GET request to a REST API, but it keeps failing due to the following error:
Failed to load resource: net::ERR_CERT_AUTHORITY_INVALID
Any ideas on why this may be happening or a workaround? Maybe this is a restriction of webviews?
If I make the call in the extension code, it works fine.
I upgrade the version of my browser to the latest and it worked me.
find this below given link to know how to update browser version.
https://www.computerhope.com/issues/ch001388.htm
Assuming that you get this error about the certificate of the remote side (the one serving the REST API), you get this error because of one of the following:
the authority that signed the certificate is not recognized on the client side (ie : the authority is not installed on your PC)
the certificate has expired
your PC has a wrong date
You can correct the above, or as a workaround you can (depending on your tools) explicitly ignore the untrusted remote certificate. But this workaround should remain for test purpose only, as it is a security breach.

Response not returned for specific requests when xdebug running

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!

Calling a https WCF-Service from Silverlight 4 only works with fiddler and from VS2010

for days now, I try to get the following scenario running:
I have a Silverlight 4 Application that calls a WCF-Service via HTTPS. The WCF-Service is located on one of our servers, the Silverlight 4 app is also served from this server. After several hours of trial and error (well actually more error than try) I get it running when starting it from my VS2010 development environment on my local machine (see also SecurityError when calling a HTTPS-WCF Service from Silverlight 4).
But ...
The call to the https-WCF ONLY works when I start the SL-App from my VS2010 AND when fiddler is running and after I tell fiddler to ignore the Certificate Error (I use a self-signed certificate). When fiddler is not running, I get a security error. That applies, when my browser is the IE. When I copy the localhost address from the IE and paste it in my opera, it works without fiddler.
When I deploy the Silverlight app to the server and call it from the server, the WCF-call doesn't work, whether fiddler is running or not. I just get the standard Message, that an exception has occurred. This happens in both Opera and IE. Fiddler doesn't ask me to ignore the Certificate Error like it does in the VS2010 scenario, so maybe there is somewhere the key to my problem. Unfortunately, I have not much experiences with this stuff, so I have no idea, where to look or what to do.
I already found something about the fiddler issue here on stackoverflow ( Silverlight Requests, Failures & Fiddler), but it doesn't help me solving my problem.
I hope that some of you can shed some light in this issue, before all my hair is turned to gray.
Thanks in advance,
Frank
Edith has just installed the Certificate as a trusted Certificate in IE - but I still get the error, when calling the WCF when starting the deployed silverlight app from the server. At least I can call the Service when I start the SL app from VS2010 in the IE now (even when that doesn't help me, when some one else has to work with the app.
Several thoughts:
What is the exact error message you're seeing? Any inner exceptions?
Could this be a cross-domain issue? (Are the Silverlight XAP and the WCF service hosted from exactly the same domain, including its HTTP vs HTTPS characteristic, port number, distinction between "localhost" and an actual machine name, etc? What is the exact address as it appears in ServiceReference.ClientConfig or in code, and does its domain name exactly match the XAP's domain name?)
Do you see any call attempting to go through in Fiddler at all when it fails? (If not, I would strongly suspect a cross-domain issue)
If you manually browse to the https://....../YourService.svc from IE/Opera (instead of invoking the service through code in Silverlight), can you successfully see the service information page, with no certificate warnings/errors?
Does your SSL certificate has the same name as your service host? If not, that causes an error which can lead to the described behavior

CakePHP's Auth->Login not working in production, but works in test

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.

Resources