I am using inetc plugin of NSIS. And I am trying to call one URL which uses HTTPS protocol. The URL gives me SendRequest error.
As posted this seems to be solution
But I'm unsure how to set the flags as told by #Anders
Anyone has any pointers regarding this?
Thanks in advance,
Regards,
- Ganesh
INetC uses the SECURITY_FLAG_IGNORE_UNKNOWN_CA and SECURITY_FLAG_IGNORE_REVOCATION WinINet flags but it does not use SECURITY_FLAG_IGNORE_CERT_DATE_INVALID nor SECURITY_FLAG_IGNORE_CERT_CN_INVALID. Like I suggested in the other answer, you should ask the author of this plugin to add a /nosecurity flag if you believe you need these flags or just use plain HTTP.
Related
I'm trying to add a netconf-connector into my Open Daylight Nitrogen controller and keep coming up against this error:
">Error parsing input: Could not find module for namespace urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf"
I'm posting to rest via the postman application using the below URL and Schema used in the guide below:
"http://192.168.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules"
Has anyone had the same issue, this is the guide I'm following..
http://docs.opendaylight.org/en/stable-nitrogen/user-guide/netconf-user-guide.html
I found the same issue reported on the old Open Daylight forum but it went un-answered..
https://ask.opendaylight.org/question/28561/error-adding-node-to-odl-via-restconf/
Thanks,
Simon
Judging from the error message, you tried to use the controller-config loopback mechanism. This mechanism was deprecated and I believe was completely removed in Nitrogen (unfortunately the documentation wasn't updated to indicate this). Either way, you should use the mechanism outlined in the "Netconf-connector configuration with MD-SAL" section.
Can someone using CF10 confirm if CF10 supports secure websocket wss://?
http://blog.kaazing.com/2012/02/28/html5-websocket-security-is-strong/
I checked with Hemant. The answer is no, it is NOT supported now, but it is under progress to be added.
On the basis of there being not a single mention of "secure websocket" or "wss" in the CF10 docs (according to Google), and in all the blogging Ray Camden has done on the topic there is not a single mention of it either, and indeed the only relevant match on all of Google for "cf10 wss" is back to this very question, I would say "no".
But that would be rather an odd implementation omission, I think.
I just tried hacking this on the websocketChannel.js file where the URL is created (line 18)
var lURL="ws://"+(_7e0)+":"+_cf_websocket_port+"/cfusion"+"/cfusion";
tried to do this
var lURL= (location.protocol === "https:" ? "wss" : "ws") + "://"+(_7e0)+":"+_cf_websocket_port+"/cfusion"+"/cfusion";
But alas the wss:// connection would just never connect. BS I tell you .. pure BS!! The only issue really is with IE10 as it will not connect to an unsecured websocket channel initiated from a secure page.
No it is not supported yet. However, it is being considered for
ColdFusion Splendor.
https://twitter.com/rakshithn/status/352722362799624193
This question is follow-up for this topic:
Configuring MODx Revolution to work with both http and https.
For even more details see this
MODX forum post
I face the same problem as described there and I use suggested solution. Just in my case I found the situation when it does not work.
I use MODX extra called FormIt (you probably know it) - it processes the forms and then redirects to 'thank you' page. What I have problem with is this redirect. It also uses makeUrl() but the snippet mentioned in the original post does not help here because in FormIt class the whole context config is regenerated, so site_url contains again [[++url_scheme]] and redirect ends in address like:
https://www.example.com/[[++url_scheme]]www.example.com/[[++url_scheme]]www.example.com/thank-you-page.html
instead of
https://www.example.com/thank-you-page.html
I wonder if you could know about some workaround, please?
thank you in advance!
Succeeded to resolve the issue.
What helped was to create new hook which does something like:
$modx->config['site_url'] = $modx->config['url_scheme'] . substr($modx->config['site_url'], strlen('[[++url_scheme]]'));
and then add this hook right before redirect hook in FormIt call
I installed dredd - API Blueprint Testing Tool and trying to test our APIary API against the implementation.
In the blueprint I have just one resource which is correctly implemented on somehost... but test fails :(
test command:
dredd apiary.apib http://somehost.de:8443/imp-endpoint
output:
Info: Beginning Dredd testing...
undefined
I tried also with more options to get more information what is undefined.. like -l verbose and some other options. But I did not get more information about the failure :(
Does anyone have experience with it? Thank you!!! :)
Answered on Github but I'll reproduce the main points here for reference:
I wasn't able to to reproduce your "undefined" problem, but there are a few issues that, when corrected, make everything work.
At the moment, the base url can't have a path in it (see #43). This is solved in #45 but hasn't yet been merged. So your command should be 'dredd apiary.apib http://somehost.de:8443/' and then '/imp-endpoint' should be a prefix on the urls.
The URI template is incorrect in your apib file. Instead of /api/V0/Resources/CarSharing/Cars?{lat}&{lng}&{radius}, it should be /imp-endpoint/api/V0/Resources/CarSharing/Cars{?lat,lng,radius}. See RFC6750 for reference.
The line-endings should be Unix style, not Windows (\n, not \n\r). When I first ran the apib you provided, I got the error: the use of carriage return(s) '\r' in source data isn't currently supported, please contact makers (this is actually enforced by the blueprint parser, see snowcrash)
Hope that helps! I get a 401 when running the test, so you'll need to provide HTTP Basic authentication information (this can be done in the header section of the blueprint or with the -u flag on dredd, as in -u username:password)
I found the source of my problem for SuperAgent (http://visionmedia.github.com/superagent/) on Firefox. Not sure if SuperAgent is doing it in its AJAX call or if FireFox is triggering it.
Essentially, every time I make an AJAX call an OPTIONS method is being fired on the URL before the actual AJAX call. Quite annoying since the server currently doesn't support OPTIONS. How can I make a call without it going to crap and re-coding the server?
Thanks
Ok found out some more details. Thankfully testing on Safari gave me more insight into what was actually happening and I applied my knowledge here.
It seems to be the standard that browsers are calling an OPTIONS method before making an actual AJAX call. Seems a bit overbearing.
So to get around it I simply added a catch-all in my reverse proxy server to handle each OPTIONS call. You can see the question below for the code:
Play! 2.0 easy fix to OPTIONS response for router catch-all?
And if you want to read up more on why browsers are doing this, see here:
Why am I getting an OPTIONS request instead of a GET request?
OPTIONS is from the CORS standard.
Disabling web-secuty in phantomjs also helped to resolve this problem (--web-security=no). Because I didn't have access to API server to make changes for OPTION method.