這是一個我認爲我理解的概念,但最近發現我錯了。我查看了互聯網上的所有內容,並找到大量小細節和代碼片段的示例,但我仍然缺乏對它的阻止以及爲什麼阻止它以及爲什麼阻止它的理解。所以這更多的是要求高層次的解釋而不是問題。交叉來源xhr和同源政策
不管怎麼說,這裏就是我想我瞭解:
比方說,我有域A.com和域B.com。每個人都擁有自己的IP地址的apache服務器。 我從域A.com加載一個HTML文件到瀏覽器中。瀏覽器執行POST XMLHttpRequest到B.com/doStuff.php,由於設置了相同的域策略而失敗。
所以: 誰是同域名政策是相關的?我認爲答案是B.com/doStuff.php ...對不對?因此,當A發送請求時,B檢查請求標頭的來源,並說「哎呀,不同的域,不會聽你的」。或者A發送請求,B響應指定「same-domain-policy」的頭部,然後瀏覽器檢查該請求,因爲指定了same-domain-policy,並且A請求頭部的域不匹配來自B的請求BROWSER拒絕發送xhr?
如果是這樣的話,似乎不允許跨原點請求的一點是,因爲「我不想比我之外的任何人訪問我的API」。這就是全部?因爲你不想用某種認證來解決這個問題嗎?難道有人只是構造一個假源頭的HTTP請求(簡單地說謊)?
或者這是否應該保護用戶?如果是這樣的話,如何防止他們調用你的API來保護任何人?
我很困惑...
不會搶奪使用URL,例如停止機器,捲曲,它只是試圖阻止基於瀏覽器的抓取。要阻止非js威脅,您必須進行身份驗證。關鍵是一個網站的內容不能通過未經簽名的JS重新嵌入,而不需要你明確地允許它。 – dandavis
@dandavis不是那麼容易迴避嗎?只需要你的服務器獲得它的javascript請求(例如curl),然後將它傳遞迴javascript ...有什麼意義? – Phildo
重點是控制和問責:服務器/ php代碼註冊到信用卡,普通舊網頁不是。在你的例子中,執行curl的服務器可以很容易地識別和阻止,但是如果流量來自廣告注入的javascript,請求可能來自任何地方... – dandavis