I'm trying to generate requests to fire at our new versions of our .net web apps in IIS in order to start the app pools and warm them up.
The different versions are bound to local IPs and I'm trying to hit them with the following request as it looks like it will do the job:
Invoke-WebRequest 'http://172.28.36.31' -Headers #{host="www.mydomain.com"}
Now got the above working.
Any ideas on getting the same request to work over https and ignore and self signed cert warnings? There's a couple of options to ignore the warnings but haven't seen anything to use an ip with a custom host (akin to a local host entry)
You are getting a non-success http status code from the server which makes PowerShell throw an exception. Based on the "Object moved to here" message I assume it's going to be a redirect response.
You can check the status code by modifying your call like this:
try {
$response = Invoke-WebRequest 'http://172.28.36.31' -Headers #{host="www.mydomain.com"}
} catch {
$_.Exception.Response.StatusCode.Value__
}
Related
I am creating a GroupMe bot, and I'm testing out the callback URL and the basic WSGI app I've set up so far. I am planning host the bot on Heroku, but am testing it on my local machine first. I registered a bot, with the callback URL http://MY_IP_ADDRESS:8000. When I open a different shell and run requests.post('http://MY_IP_ADDRESS:8000', data = 'something') in the Python interpreter, everything works fine. However, when there is activity in the GroupMe group, nothing happens, not even an error message.
Here's my (simplified) code:
from wsgiref.simple_server import make_serve
def app(environ, startResponse):
try:
requestBodySize = int(environ.get('CONTENT_LENGTH', 0))
except ValueError:
requestBodySize = 0
# requestBody = environ['wsgi.input'].read(requestBodySize)
print('something')
responseBody = bytes('successful', 'utf-8')
status = '200 OK'
responseHeaders = [('Content-Type', 'text/plain'), ('Content-Length', str(len(responseBody)))]
startResponse(status, responseHeaders)
return [responseBody]
server = make_server('', 8000, app)
server.serve_forever()
I'm sure I'm doing something obvious, but I can't for the life of me figure out what. I'd appreciate any help!
I never figured out why the callback URL wasn't working with localhost, but when I deployed the app on Heroku, everything worked fine! It must have had something to do with my firewall settings.
When you run servers on your local machine your firewall doesn't really like that. GroupMe also cant send to anything but public facing addressees, which is why Heroku works. One thing I can recommend in the future is using Ngrok, https://ngrok.com/ this will work with your server to make a public facing address on your machine that you can use as callback url. I use Ngrok to test my bots and quickly iterate before pushing to a dedicated server like Heroku, honestly looking through Heroku log files is a pain...
I've created a new API Proxy and deployed revision 1 into production, but when I call my API I just get:
HTTP 500 Internal Server Error
{
"fault": {
"faultstring": "Internal server error APIProxy revision 1 of MyProxy does not exist in environment prod of organization MyOrg",
"detail": {
"errorcode": "messaging.adaptors.http.ServerError"
}
}
}
Not the most helpful error message in history. Any pointers where to start debugging this would be very helpful, thanks!
You appear to be using the wrong url for your API, so it could not be found. If you haven't added any API key checking or additional authorization, you should be able to copy the url directly from the API details page in the prod Deployments line. Start a trace session and paste that url into the URL box. Test what happens when you do that trace.
If you have any additional security or other features that would alter the API, you would need to make those changes to the URL before sending it. If you're still having a problem, send an email to help#apigee.com.
I have C#/ASP.NET web service which is running on a remote server and uses WSDL. It worked fine up until recently when it was moved to another server. However this means I had to change the database connection string, which was hard coded, so the code needed to be rebuilt on my development machine and uploaded to the server.
The service is called from a PHP script running on another web server using SOAP.
For some reason, from what I can tell, it's trying to run the old code, even though I've modified it.
e.g. if I change my web service function to just return, for example, "Hello, World", it seems to still try to connect to the database, etc. (but failing because that database no longer exists, I believe it's still trying to use the old connection string)
If I remove the function, it tells me that the function doesn't exist. (So it is looking in the right place)
If I add a new function and try to call it from the php script, I get the error
The server did not recognize the value of HTTP Header SOAPAction
If I try and test it on the actual server using the http://localhost/Myservice/Myservice.asmx everything works fine!
Here is the code I am using to call:
ini_set("soap.wsdl_cache_enabled", 0);
$client = new SoapClient("http://1.2.3.4:8083/MyService/MyService.asmx?WSDL&revision=1", array('cache_wsdl' => WSDL_CACHE_NONE));
$input = new stdClass;
$input->inputvals = '15707F';
echo "Functions: |";
print_r($client->__getFunctions()); // Lists all functions including new ones
echo "|\n\n";
$Response = $client->checkPrice($input);
print_r($Response);
To deploy the code this is what I'm doing - on local development machine, I Publish the solution to File System (for some reason I can't get IIS working on this machine). Then stop IIS on server machine, "Remove Application" in IIS, copy my files in, "Convert to Application", then restart IIS.
The server seems to get a wrong SOAPAction HTTP-Head attribute (which is part of the SOAP-standard) from your SOAP-Client. Check the wsdl for the expected one (wsdl:binding section) and make sure that you're sending it with the expected value.
OK, I'm not completely satisfied with this solution but here is how I got it working.
I don't know enough about WSDL to know why or how this happens, but the WSDL xml file had the following lines in it (as per my comment on my own original post).
<wsdl:service name="Myservice">
<wsdl:port name="MyserviceSoap" binding="tns:MyserviceSoap">
<soap:address location="http://1.2.3.4/Myservice/Myservice.asmx" />
</wsdl:port>
.
.
.
</wsdl:service>
Note the lack of the :8083 port on the location. Originally I had moved the service from 1.2.3.4 to 1.2.3.4:8083 in order to keep it running during the transition - the router then uses NAT to forward it to the correct server on their internal network. When the owners of the server had said they turned off, all they had turned off was the MS SQL server on that computer, so my old web service was still working away. (I had kind of taken their word for it when they said they had turned off the server)
To work around this, I overrode the __doRequest() function in the SoapClient class in my PHP client script to manually add the :8083 to the URL of the location.
class SoapClient8083 extends SoapClient
{
public function __doRequest($request, $location, $action, $version, $one_way = 0) {
$location_parts = explode("//", $location);
if (count($location_parts) == 2) {
$location_url_parts = explode("/", $location_parts[1]);
$location_url_parts[0] .= ":8083";
$new_location = $location_parts[0] . "//" . implode("/", $location_url_parts);
}
if (isset($new_location) && $new_location)
$location = $new_location;
return parent::__doRequest($request, $location, $action, $version, $one_way);
}
}
So it was getting the function list from the correct place which was why it was correctly recognising when I removed the function, but then contacting the wrong place to actually implement the functions.
... 8 hours of trying to debug later ...
Anyway, I'd rather not stick with this solution and instead figure out why the WSDL doesn't put the port number on the <soap:address location... />
Thanks for the responses - they did encourage me to look in the right direction...
I have an ASP.Net web application running on Windows Server 2012, and need to make calls to social networking sites using oauth to generate some of the page content. Everything works on my development machine, but I can't even get a single response back ("unable to connect to the remote server" error).
I disabled the firewall to test that. No luck. I created a console application to test it that way. A simple HttpWebRequest will get the html for any page I throw at it, but not any oauth request. I've used different libraries to try to achieve this, including Linq2Twitter, Spring.Social, and HigLabo. All work locally, but not on the server. I've found nothing useful in the server event log.
Can anyone give me some clues what might be happening?
EDIT: Here's some code I'm using with the HigLabo library to try to retrieve the user timeline.
using HigLabo.Net.Twitter;
var cl = new TwitterClient(consumerKey, consumerSecret, accessToken, accessTokenSecret);
var rr = cl.GetHomeTimeline();
foreach (var r in rr)
{
//Console.WriteLine(r.CreatedAt + ":" + r.Text);
}
I'm aware that accessToken & accessTokenSecret aren't/shouldn't be necessary for a simple timeline read, but this is just to make sure it works first.
This turned out to be a firewall issue, as had been suspected. But not the server firewall. This was a problem with the ISP. They had an internal firewall that was blocking all traffic to/from the social network sites. They were able to resolve it quickly with a phonecall, but it was not a coding or configuration error on my part.
IS there a way to trick the server so I don't get this error:
Content was blocked because it was not signed by a valid security certificate.
I'm pulling an iframe of an html website into another website but I keep getting the console (chrome) error in the title of this question and in internet explorer it says:
Content was blocked because it was not signed by a valid security certificate.
Your resource probably use a self-signed SSL certificate over HTTPS protocol.
Chromium, so Google Chrome block by default this kind of resource considered unsecure.
You can bypass this this way :
Assuming your frame's URL is https://www.domain.com, open a new tab in chrome and go to https://www.domain.com.
Chrome will ask you to accept the SSL certificate. Accept it.
Then, if you reload your page with your frame, you could see that now it works
The problem as you can guess, is that each visitor of your website has to do this task to access your frame.
You can notice that chrome will block your URL for each navigation session, while chrome can memorise for ever that you trust this domain.
If your frame can be accessed by HTTP rather than HTTPS, I suggest you to use it, so this problem will be solved.
Sometimes Google Chrome throws this error, even if it should not.
I experienced it when Chrome had a new version, and it needed to be restarted.
After restarting the same page worked without any errors.
The error in the console was:
net::ERR_INSECURE_RESPONSE
I still experienced the problem described above on an Asus T100 Windows 10 test device for both (up to date) Edge and Chrome browser.
Solution was in the date/time settings of the device; somehow the date was not set correctly (date in the past). Restoring this by setting the correct date (and restarting the browsers) solved the issue for me. I hope I save someone a headache debugging this problem.
Offering another potential solution to this error.
If you have a frontend application that makes API calls to the backend, make sure you reference the domain name that the certificate has been issued to.
e.g.
https://example.com/api/etc
and not
https://123.4.5.6/api/etc
In my case, I was making API calls to a secure server with a certificate, but using the IP instead of the domain name. This threw a Failed to load resource: net::ERR_INSECURE_RESPONSE.
open up your console and hit the URL inside. it'll take you to the API page and then in the page accept the SSL certificate, go back to your app page and reload.
remember that SSL certificates should have been issued for your Dev environment before.
If you're developing, and you're developing with a Windows machine, simply add localhost as a Trusted Site.
And yes, per DarrylGriffiths' comment, although it may look like you're adding an Internet Explorer setting...
I believe those are Windows rather than IE settings. Although MS tend to assume that they're only IE (hence the alert next to "Enable Protected Mode" that it requries restarted IE)...
Try this code to watch for, and report, a possible net::ERR_INSECURE_RESPONSE
I was having this issue as well, using a self-signed certificate, which I have chosen not to save into the Chrome Settings. After accessing the https domain and accepting the certificate, the ajax call works fine. But once that acceptance has timed-out or before it has first been accepted, the jQuery.ajax() call fails silently: the timeout parameter does not seem help and the error() function never gets called.
As such, my code never receives a success() or error() call and therefore hangs. I believe this is a bug in jquery's handling of this error. My solution is to force the error() call after a specified timeout.
This code does assume a jquery ajax call of the form jQuery.ajax({url: required, success: optional, error: optional, others_ajax_params: optional}).
Note: You will likely want to change the function within the setTimeout to integrate best with your UI: rather than calling alert().
const MS_FOR_HTTPS_FAILURE = 5000;
$.orig_ajax = $.ajax;
$.ajax = function(params)
{
var complete = false;
var success = params.success;
var error = params.error;
params.success = function() {
if(!complete) {
complete = true;
if(success) success.apply(this,arguments);
}
}
params.error = function() {
if(!complete) {
complete = true;
if(error) error.apply(this,arguments);
}
}
setTimeout(function() {
if(!complete) {
complete = true;
alert("Please ensure your self-signed HTTPS certificate has been accepted. "
+ params.url);
if(params.error)
params.error( {},
"Connection failure",
"Timed out while waiting to connect to remote resource. " +
"Possibly could not authenticate HTTPS certificate." );
}
}, MS_FOR_HTTPS_FAILURE);
$.orig_ajax(params);
}
This problem is because of your https that means SSL certification. Try on Localhost.