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
Related
I am busy with implementing payments using Sage Pay direct protocol 3.0
(4,0 unavailable yet as I understand)
I register transaction using vspdirect-register.vsp
I redirect user to ACSURL with MD, PAReq and TermUrl using POST
I catch user on TermUrl and check transaction status using direct3dcallback.vsp with MD and PARes
BUT on this stage I always get:
STATUS: 'OK'
AVSCV2: 'ALL MATCH',
StatusDetail: '0000 : The Authorisation was Successful.',
AddressResult: 'MATCHED',
PostCodeResult: 'MATCHED',
CV2Result: 'MATCHED',
'3DSecureStatus': 'ERROR'
Using MySagePay tools I get an explanation like :
3D secure status The authentication callback message was MALFORMED. No 3D-Authentication occurred! ERROR
Attempt 1
ECI result Unknown result type
How can I debug this error?
Is it normal that I get status OK even when 3DSecureStatus : ERROR ?
Q1: Why are you getting a 3-D Secure error?
The MALFORMED status points towards SagePay not being able to read your request .. (e.g it's syntactically or structurally invalid etc).
Given the lack of code in the OP, rather than try and guess what you're doing wrong, I'll instead show what we do (which works - we've implemented both v3.00 & 4.00).
We perform an HTTP POST with the following parameters to https://live.sagepay.com/gateway/service/direct3dcallback.vsp (or https://test.sagepay.com/gateway/service/direct3dcallback.vsp in the case of testing):
For direct protocol v3.00
VPSProtocol: "3.00"
MD: MD posted to TermURL (e.g 20156570522002324295)
PARes: "PARes posted to TermURL"
For direct protocol v4.00
VPSProtocol: "4.00"
VPSTxId: VPSTxId from the initial payment response (Note that curly brackets {} need to be removed!!!)
CRes: "CRes that was posted to the ThreeDSNotificationURL"
Q2: Why do you get an OK status when 3-D Secure failed?
I believe this is probably due to your merchant ruleset. You can state what you want to happen with the transaction if 3-D Secure is unavailable or fails.
So, check your ruleset. I believe that we force our consumers through 3-D Secure as our chargeback percentages were quite high otherwise.
Footnote
I would also concur that since you are doing this work, it would probably be more beneficial to implement version 4.00, since that means the majority of your customers should have a better experience, and you'll have a better conversion rate too. Win win.
HTH.
Protocal 4.0 is available on the SagePay test server and you can start working on that already. It needs to be implemented by the 14th of September 2019 and the last info I've got from SagePay support staff is that the protocal 4.0 will be on the live server by the 14th of September 2019.
To your probelm: I call the ACSURL with the added query string for MD, PaReq, TermUrl which works ok.
I see that you posted PAReq. Please note that I use PaReq. A small a instead of a capital A. See page 16 of the Documentation. DIRECT_Integration_and_Protocol_4_Guidelines.pdf
Maybe you could post the complete URL you post to SagePay.
Hope this helps.
Thanks guys!
Sage support have helped me to find issue.
The point was - route 'ThreeDSNotificationURL' make changes in 'CRes' as we have configured some security behaviors, and when we check this key on Sage side - we got an error. so some extra security behaviors for this route have solve the issue.
Thanks guys!
I have searched the answers to similar questions asked about this SagePay error, and checked that the fixes don't appear to apply to my problem.
Specifically:
I am using a correct 2-letter country code for BillingCountry and DeliveryCountry.
I am POSTing VPSProtocol, TxType and Vendor as well as the Crypt value.
I have re-checked that I am using the correct encryption key from the MySagePay test portal.
Now I was using http://localhost:8084/app/success and http://localhost:8084/app/failure for my success and failure URLs, since I thought that although these are (obviously) not visible externally, it shouldn't matter since SagePay is re-directing at the end of its part of the transaction. (Is this assumption correct, or do these URLs need to be externally accessible?) Some of the answers have thrown doubt on this, so I changed them to an external website I own, and I still get the same error.
Another line of thought is that the client I am developing for has already gone live, and there seem to be hints that once you have gone live, you no longer have access to the test server (Is this true?)
Is there anything else I should be checking? (Additional info: I'm using the SagePay api (sagepay-api-1.2.2.0.jar and related libraries) to validate the form contents and encrypt them.
I used the integration from https://github.com/tolzhabayev/sagepayForm-php
I had this error (5080) and spoke to SagePay support and they guided me to the MySagePay portal where you can view Invalid transactions to be able to troubleshoot this error easily!
Hope this helps someone.
Chris Rickards
I had exact same problem and I tried everything that you described as well, one day after I found that the problem was in "VendorEMail" field, it had 2 email addresses separated by ;, once I removed second and left only one email everything worked.
i've got a little problème im not even abble to clearly formulate.
And this didnt helped me finding an answer on the internet.
So I rely on you people if somehow you have allready encouter this problem or either simply had an idea of where this could came from.
Here is my problem : When I try to connect on my personal website the navigator (Chrome or Firefox, haven't test with others) told me the certificate of security is invalid and is only valid for ssl1.ovh.net (ovh is my web hosting-provider).
The error code is : ssl_error_bad_cert_domain.
Well if any of you has an idea of where this could came from ?
Here is my website if some wants to have a look : maelmayon.fr
Thank you for reading it, I hope someone could help me.
Even though this is not a solution to the underlying problem, this is a nice workaround.
Either add a security exception in your browser, or explicitly link via http://. The security violation report should only show when trying to connect via https://.
I think you'd have to contact your provider for a shared SSL certificate to enable connection via https
We have a websocket server on port 8080 setup on a Linode box. Chrome and Opera work just fine. Firefox however complains that the operation is insecure.
"The operation is insecure: Code 18"
If I try to create a new WebSocket object in the web console before the page is loaded everything is fine. However, after the page loads something is screwy then I cannot create the object anymore. See the attached screenshot.
I have no idea what operation is insecure or even how to go about diagnosing this.
As you point out in another answer, https:// to ws:// is disallowed by default on firefox.
Going to firefox's about:config and toggling network.websocket.allowInsecureFromHTTPS will get rid of the SecurityError.
I fixed this. The app itself is under SSL but the websocket being accessed is not. Chrome and Opera don't care but Firefox does. According to:
https://bugzilla.mozilla.org/show_bug.cgi?id=303952
This is known and is not considered a bug. Mozilla's response: wontfix
Solution, put websocket server under SSL and use wss://
This is a hunch based off limited info, and I probably should put this into a comment, but I don't have enough reputation points to do that yet.
Looking at your log, it seems as if 24 seconds are passing from the receipt of [object Websocket] (time 17:46:36.683) until you get The connection to ws://.....(time 17:47:00:952) error message.The long delay leads me to believe that the server could be timing out and closing the websocket connection. Look at this answer for a potential solution.
Had the same problem and attempted to fix by changing network.websocket.allowInsecureFromHTTPS in about:config which did not work.
Ended up finding this post => Unhandled Rejection (SecurityError): The operation is insecure. On a fresh create-react-app project
Changing this in index.js ended up working for me
serviceWorker.register();
//serviceWorker.unregister();
Open "about:config" url in firefox. Search for allowInsecureFromHTTPS and set it to true
Beside secure ssl context and cross-origin policies, assigning some port can trigger the error as well.
What are valid http ports for Firefox? I don't know precisely, but have to be between 1500 and 64000, or the console will display:
SecurityError: The operation is insecure.
And http links will say:
This address is restricted
This address uses a network port which is normally used for purposes other than Web browsing.
Firefox has canceled the request for your protection.
I've read somewhere that the trunk version of Firefox already had a WebSocket implementation. Nevertheless, I've just tried the 3.7a4pre without success. It still
gives me the old "WebSocket is not defined" error message. Am I confused with WebWorkers?
Using a flash-based WebSocket implementation is not an option.
Please advice.
According to bug 472529 a patch has not yet been applied to trunk.
WebSocket (both the API and the wire protocol) are still in draft, so we're a way off yet.
Using a flash-based WebSocket implementation is not an option.
I'm afraid a fallback (Flash, Java, XMLHttpRequest long-polling etc.) is your only option in Firefox for now. The only browser that currently has native WebSocket is Chrome.
WebSockets has been just landed on Firefox trunk.
WebSockets disabled in Opera and Firefox 4: http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/
They are called MozWebSockets on Firefox since v4
Check out the Mozilla Websocket Reference
Since Firefox supports WebSockets not strictly to official standards it had prefix "Moz", so you have to check if WebSocket is existing object, if yes use it, if no check MozWebSocket, if yes, then use it.
Since Firefox 11, they do support WebSockets without prefix, so it is the same as in Chrome now.