Fetch

直接結論：此路不通。 我知道 fetch 寫起來很優雅，也是現代標準，但在跨伺服器 (Cross-Origin) 且 對方伺服器沒開 CORS (Access-Control-Allow-Origin) 的情況下，fetch 會被瀏覽器直接殺死。 這不是你程式碼寫錯，而是瀏覽器底層的安全機制 (Same-Origin Policy) 擋住了你。 為了讓你徹底死心（或是驗證你的伺服器有沒有開權限），我把標準的 fetch 寫法給你。你可以試一次，然後看 Console 的報錯。 🧪 實驗用代碼：用 Fetch 挑戰跨域 請將這段 JS 放在你的 .ascx 裡執行： function tryFetch(rType, qYear, qMonth, who) { var url = 'http://ntcoaap20/pscc/RDPTCRpt/ReportViewer'; // 準備參數 var formData = new URLSearchParams(); formData.append('ReportType', rType); formData.append('queryYear', qYear); formData.append('queryMonth', qMonth); formData.append('applyer', who); console.log("🚀 Fetch 發射中..."); fetch(url, { method: 'POST', body: formData, mode: 'cors', // 告訴瀏覽器這是跨域請求 credentials: 'include' // 【關鍵】這行是為了存 Cookie/Session }) .then(response => { // 如果伺服器沒設定 CORS Headers，程式碼會在這一行之前就報錯，跑進 catch if (!response.ok) throw new Error('Network response was not ok'); return response.json(); }) .then(data => { console.log("🎉 奇蹟發生了！Server 回傳:", data); // 如果能執行到這，代表對方伺服器有開 CORS，你就可以用 window.open(data.redirecturl) }) .catch(error => { console.error("💀 任務失敗:", error); alert("Fetch 失敗！原因：跨域被擋 (CORS) 或 混合內容錯誤"); }); } 🔮 我預測你會看到的結局 當你按下按鈕，F12 Console 會有 99% 的機率出現這行紅字： > Access to fetch at 'http://ntcoaap20/...' from origin 'http://你的網站...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. > 為什麼會這樣？(技術真相) * CORS 檢查： 瀏覽器發現你在 A 站呼叫 B 站的 API。它會檢查 B 站的回應表頭有沒有寫 Access-Control-Allow-Origin: http://你的網站。 * 現況： 舊的 ASP.NET WebForms 應用程式 (ntcoaap20) 通常預設不會加這個表頭。 * 結果： 瀏覽器攔截回應，丟出 Error。 * Cookie 寫入失敗： 就算你用了 credentials: 'include'，如果 CORS 檢查沒過，瀏覽器為了安全，絕對不會把 B 站回傳的 Set-Cookie 寫入瀏覽器。 * 結果： Session 沒存進去。之後你開報表頁面，會因為沒有 Session 而顯示空白或錯誤。 ⚡ 總結 * 同網域 (你的網頁也在 ntcoaap20)：Fetch 可用 ✅ (最優雅)。 * 跨網域 (你的網頁在別台)：Fetch 必死 ❌。 請回到上一則提到的「誘餌戰術 (Form Submit + Target=_blank)」。 因為 Form Submit 不受 CORS 限制，它是目前能在跨域環境下把 Session 寫進去的唯一解法。