I was asked a question below and cannot find the answer. I looked up similar posts, but many posts (like this) ended up talking about cross-origin, not cross-domain. What is the answer to the below question?
Q: Assume you are working on a webpage at http://example.com/path/to/foo.html.
if you were to send an AJAX request to the following URLs, which one would NOT trigger a cross-domain violation?
A: http://example.com/bar
B: https://example.com/path/to/bar.html
C: https://example.com:80/bar
D: http://www.example.com/bar
E: C and D
Thank you in advance.
UPDATE:
Originally, I came across a website saying there is a 'Cross-domain violation' which is different from 'CORS' since 'origin' and 'domain' points different part. That's why I have been looking for the definition of 'cross-domain violation'. But it was actually the same as 'same-origin policy', as the answer below shows.
Due to this:
A resource is cross-origin when it's located at a different
(sub)domain, protocol, or port!
You should also use exact match host so http://www.example.com/bar doesn't work out.
Take a look at this to see more examples.
You should not get CORS in the A option.
And also this article fully describing CORS.
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.
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
There are several topics about the problem with cross-domain AJAX. I've been looking at these and the conclusion seems to be this:
Apart from using somthing like JSONP, or a proxy sollution, you should not be able to do a basic jquery $.post() to another domain
My test code looks something like this (running on "http://myTestdomain.tld/path/file.html")
var myData = {datum1 : "datum", datum2: "datum"}
$.post("http://External-Ip:port", myData,function(return){alert(return);});
When I tried this (the reason I started looking), chrome-console told me:
XMLHttpRequest cannot load
http://External-IP:port/page.php. Origin
http://myTestdomain.tld is not allowed
by Access-Control-Allow-Origin.
Now this is, as far as I can tell, expected. I should not be able to do this. The problem is that the POST actually DOES come trough. I've got a simple script running that saves the $_POST to a file, and it is clear the post gets trough. Any real data I return is not delivered to my calling script, which again seems expected because of the Access-control issue. But the fact that the post actually arrived at the server got me confused.
Is it correct that I assume that above code running on "myTestdomain" should not be able to do a simple $.post() to the other domain (External-IP)?
Is it expected that the request would actually arrive at the external-ip's script, even though output is not received? or is this a bug. (I'm using Chrome 11.0.696.60 )
I posted a ticket about this on the WebKit bugtracker earlier, since I thought it was weird behaviour and possibly a security risk.
Since security-related tickets aren't publicly viewable, I'll quote the reply from Justin Schuh here:
This is implemented exactly as required by the spec. For simple cross-origin requests http://www.w3.org/TR/cors/#simple-method> there is no pre-flight check; the request is made and the response cannot be read if the appropriate headers do not authorize the requesting origin. Functionally, this is no different than creating a form and using script to make an off-origin POST (which has always been possible).
So: you're allowed to do the POST since you could have done that anyway by embedding a form and triggering the submit button with javascript, but you can't see the result. Because you wouldn't be able to do that in the form scenario.
A solution would be to add a header to the script running on the target server, e.g.
<?php
header("Access-Control-Allow-Origin: http://your_source_domain");
....
?>
Haven't tested that, but according to the spec, that should work.
Firefox 3.6 seems to handle it differently, by first doing an OPTIONS to see whether or not it can do the actual POST. Firefox 4 does the same thing Chrome does, or at least it did in my quick experiment. More about that is on https://developer.mozilla.org/en/http_access_control
The important thing to note about the JavaScript same-origin policy restriction is that it is something built into modern browsers for security - it is not a limitation of the technology or something enforced by servers.
To answer your question, neither of these are bugs.
Requests are not stopped from reaching the server - this gives the server the option to allow these cross-domain requests by setting the appropriate headers1.
The response is also received back by the browser. Before the use of the access control headers 1, responses to cross-domain requests would be stopped dead in their tracks by a security conscious browser - the browser would receive the response but it would not hand it off to the script. With the access control headers, the server has the option of setting the appropriate headers indicating to a compliant browser that it would like to allow certain origin URLs to make cross domain requests.
The exact behaviour on response might differ between browsers - I can't recall for sure now but I think Chrome calls the success callback function when using jQuery's ajax() but the response is empty. IIRC, Firefox will not invoke the success function.
I get the same thing happening for me. You are able to post across domains but are not able to receive a response. This is what I expected to be able to do and happens for me in Firefox, Chrome, and IE.
One way to kind of get around this caveat is having a local php file with will call the data via curl and respond the response to your javascript. (Kind of restated what you said you knew already.)
Yes, it's correct and you won't be able to do that unless you use any proxy.
No, request won't go to the external IP as soon as there is such limitation.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
Ok this is weird.
If I make a request to a page, where it's text/html, firefox makes one request.
If I make a request to a page, where it's application/xml, firefox makes two requests.
In IE, Google Chrome, it one makes one in both cases.
Any ideas why the two requests, and how I can force just the one?
I've had a similar issue if the encoding of the page didn't match the <meta> tag. If the page was encoded using default windows encoding, but the meta tag specified UTF-8, then firefox would stop downloading once it reached a non-ascii character (e.g. æ,ø or å) and it would redownload the page from the beginning. This would mess up view counts and lots of other logic since the server side script would run twice.
It might be that if you do not start your page with <?xml ?>, but claim that it is, then Firefox will redownload the page again as html (text/html) and process it as html.
Just to add another possibility...
If the html code contains an empty img src attribute, then this causes a 2 http request in both Firefox and Chrome. Currently, those are the ones that follow the standard to the letter, which states that an empty URI reference refers to the absolute base URI.
I've had a similar problem with Firefox. Might help someone.
FF was making two HTTP GET requests while Chrome didn't.
The problem was an empty src="" attribute.
Firefox considers such empty attribs for img/script... tags as the current url and GETs the current page.
Maybe you're making the request in a way that cause HTTP Access Control features to fire?
It is a fairly new standard, and new in [FF3.5][2] that can cause double GET requests.
In case you can sniff the requests server side: see if they contain the Origin: header.
[2]: https://developer.mozilla.org/En/Server-Side_Access_Control Server-Side Access Control
In my case it was a wrong content-type header "image/jpg" sent with PHP-generated image. Double requests gone after I changed the type to "image/jpeg"
More info about this bug...
https://bugzilla.mozilla.org/show_bug.cgi?id=236858
I meet this problem too and I've figured it out.THIS may be related to Non-existent favicon.ico. details here,you can check it using following code(node.js),:
var http = require('http');
server = http.createServer(function (req,res){
console.log(req.url);
res.writeHeader(200,{"Content-Type":"text/html"});
res.end("Hello World");
})
server.listen(8000);
console.log("httpd start #8000");
the result is expected to be:
httpd start #8000
/
/favicon.ico
Found the problem.
The XML packet I was returning had a root node of <feed>
Firefox passes this twice for some reason, maybe as it's trying to identify if this is a valid ATOM/RSS feed. If not, just displays instead?
Changing root node to something else fixed the problem.
Thanks Marcus for starting me in the right direction.