Siri siaran ini diindeks di NgateSystems.com. Anda akan temui kemudahan carian kata kunci yang sangat berguna di sana juga.
Semakan terakhir: Nov '24
Post 3.3 menyampaikan beberapa berita buruk - objek pengesahan Firestore menggunakan bahagian klien untuk membekalkan maklumat tentang pengguna yang log masuk tidak tersedia di bahagian pelayan. Ini mempunyai akibat berikut:
Kod pangkalan data sebelah pelayan mesti menggunakan API Firestore Pentadbir. Ini kerana Firestore Klien kod API yang membuat panggilan tertakluk kepada "peraturan" pangkalan data yang rujukan pengesahan gagal apabila pengesahan tidak tersedia. Sebaliknya, panggilan API Admin tidak mengambil berat tentang peraturan pangkalan data. Jika anda menggugurkan peraturan, panggilan API pelanggan akan berfungsi di sebelah pelayan, tetapi ini akan membiarkan pangkalan data anda terbuka kepada serangan siber (anda telah menggunakan pangkalan data Firestore langsung anda sejak anda mula menggunakan terminal VSCode tempatan anda - fikirkan) .
Kod sisi pelayan yang menggunakan item data seperti UserName dan userEmel yang diperoleh daripada auth mesti mencari cara lain untuk mendapatkan maklumat ini.
Siaran ini menerangkan cara anda mengatasi masalah ini untuk menghasilkan apl web berprestasi tinggi yang berjalan dengan selamat dan cekap di bahagian pelayan.
Jika anda sudah terbiasa dengan tandatangan panggilan Klien, keperluan untuk beralih kepada API Pentadbir Firestore adalah satu gangguan. Tetapi anda tidak lama lagi akan terbiasa dengan perkara ini jadi ia tidak sepatutnya menahan anda dengan ketara.
Bagaimanapun, mendapatkan data pengguna adalah perkara yang berbeza. Untuk kebanyakan aplikasi, akses kepada sifat pengguna seperti uId adalah penting untuk reka bentuk mereka. Contohnya, apl web mungkin perlu memastikan bahawa pengguna hanya boleh melihat data sendiri mereka. Malangnya, mengatur perkara ini agak sukar. Ini dia:
Sila lihat kod berikut daripada
// src/routes/products-maintenance-sv/+page.svelte
<script>
import { auth } from "$lib/utilities/firebase-client";
import { onMount } from "svelte";
import { goto } from "$app/navigation";
onMount(async () => {
if (!auth.currentUser) {
// Redirect to login if not authenticated, with a redirect parameter
goto("/login?redirect=/products-maintenance-sv");
return;
}
try {
// Fetch the ID token directly
const idToken = await auth.currentUser.getIdToken();
window.alert("idToken:" + JSON.stringify(idToken));
} catch (error) {
window.alert("Error retrieving ID token:", error);
}
});
</script>
Anda melihat susunan onMount() lebih awal dalam products-maintenance-rf/ page.svelte di mana ia digunakan untuk memastikan pengguna dilog masuk. Ia kini turut digunakan untuk mendapatkan pembolehubah idToken dengan memanggil pengesahan tak segerak. currentUser.getIdToken().
Buat folder src/routes/products-maintenance-sv baharu dan tampal kod yang disenaraikan di atas ke dalam fail page.svelte baharu di dalamnya. Sekarang cuba jalankan ini dalam pelayan dev di http://localhost:5173/products-maintenance-sv. Sebaik sahaja anda log masuk (menggunakan versi /login/ page.svelte yang terakhir dilihat dalam [Post 3.4](https://ngatelive.nw.r.appspot.com/redirect?post=3.4 anda sepatutnya melihat idToken dipaparkan dalam mesej makluman.
Token ID Firebase ialah Token Web JSON (JWT). Bit JSON bermakna ia adalah objek yang dikodkan sebagai rentetan aksara menggunakan "Notasi Objek Javascript" (jika ini adalah pandangan pertama anda tentang "JSON", anda mungkin mendapati ia berguna untuk meminta latar belakang chatGPT). JSON digunakan secara meluas di mana anda perlu menghantar objek Javascript sebagai rentetan aksara. JWT JSON merangkumi semua yang anda mungkin perlu tahu tentang pengguna. Saya akan menunjukkan kepada anda cara anda mengekstrak maklumat ini kemudian dalam siaran ini - ia tidak rumit.
Mekanisme yang diterangkan dalam siaran ini menghantar "IdToken" sebagai "kuki" dalam "pengepala permintaan" yang mengiringi permintaan pelayan. "Pengepala http" ialah paket maklumat yang melalui web apabila fail page.svelte berasaskan klien menghantar permintaan kepada fail page.server.js berasaskan pelayan. Permintaan sedemikian akan dihantar setiap kali anda membaca atau menulis dokumen Firestore. "kuki" ialah rentetan yang ditambahkan pada setiap pengepala permintaan.
Susunan ini rumit tetapi dianggap sebagai selamat. Dari sudut pandangan anda, sebagai pelajar IT, ia juga menarik dan mendidik kerana ia memberi gambaran tentang dalaman reka bentuk web.
Atur cara Javascript sebelah pelanggan boleh menetapkan kuki "biasa" yang mengandungi JWT dengan mudah tetapi, atas sebab keselamatan, anda sangat tidak mahu melakukan ini. Jika anda boleh melakukan ini maka sesiapa pun boleh. Fail page.server.js sebelah pelayan, sebaliknya, boleh menetapkan kuki "http-sahaja" dalam penyemak imbas klien menggunakan panggilan set-kuki. Berikut ialah contoh:
// src/routes/products-maintenance-sv/+page.svelte
<script>
import { auth } from "$lib/utilities/firebase-client";
import { onMount } from "svelte";
import { goto } from "$app/navigation";
onMount(async () => {
if (!auth.currentUser) {
// Redirect to login if not authenticated, with a redirect parameter
goto("/login?redirect=/products-maintenance-sv");
return;
}
try {
// Fetch the ID token directly
const idToken = await auth.currentUser.getIdToken();
window.alert("idToken:" + JSON.stringify(idToken));
} catch (error) {
window.alert("Error retrieving ID token:", error);
}
});
</script>
Tetapan httpSahaja: benar di atas bermakna, walaupun kuki dipegang di sisi klien, ia tidak boleh diakses daripada Javascript. Dengan cara ini, anda boleh memastikan bahawa nilai yang anda tetapkan di sini selamat daripada gangguan.
Soalan yang anda patut tanya sekarang ialah "Bagaimanakah fail server-side page.server.js melancarkan arahan Set-Cookie untuk menetapkan idToken sedangkan ia tidak mengetahui idToken?" .
Selamat datang ke fail server.js Svelte. Ini ialah kod sebelah pelayan yang boleh dipanggil daripada kod sebelah klien dengan arahan pengambilan Javascript. Kod sebelah pelayan sedemikian dipanggil "titik akhir". Arahan ambil ialah kaedah asli Javascript untuk menyerahkan permintaan kepada "titik akhir" berasaskan web. Perintah ini membolehkan anda memasukkan data dalam permintaan dan ini adalah cara anda mendapatkan nilai idToken ke pelayan. Berikut ialah contoh:
// Set a secure, HTTP-only cookie with the `idToken` token
const headers = {
'Set-Cookie': cookie.serialize('idToken', idToken, {
httpOnly: true
})
};
let response = new Response('Set cookie from server', {
status: 200,
headers,
body: { message: 'Cookie set successfully' } // Optional message
});
return response;
dan inilah cara fail server.js penerima akan mendapatkan semula ini dan mengekstrak idTokennya.
// client-side +page.svelte code
const idToken = await user.getIdToken();
// Send token to the server to set the cookie
fetch("/api/login", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ idToken }),
});
Anda mungkin berfikir "Mengapa kod ini menggunakan arahan "mengambil" untuk "menghantar" sesuatu?" tetapi di sana anda berada. "Fetch" telah direka bentuk sebagai API serba boleh untuk membuat pelbagai jenis permintaan HTTP. Minta chatGPT untuk tutorial jika anda ingin mendapatkan latar belakang. Lihat untuk beberapa contoh.
Cadangan sekarang ialah menjadikan halaman log masuk anda bertanggungjawab untuk membuat panggilan server.js yang menetapkan kuki http sahaja pelayar. Setelah kuki ditetapkan, ia akan ditambah secara automatik pada setiap panggilan HTTP yang dibuat oleh penyemak imbas sehingga ia tamat tempoh.
Untuk menggerakkannya, cipta folder dan fail baharu untuk versi log masuk-dan-set-kuki/ page.svelte berikut bagi halaman log masuk, dan titik akhir api/set-cookie/ server.js yang disertakan:
// server-side +server.js code
export async function POST({ request }) {
const { idToken } = await request.json();
}
Perhatikan bahawa, untuk menggunakan api/set-cookie/ server.js, anda perlu memasang pustaka "cookie" npm terlebih dahulu. Pustaka ini membantu mencipta kuki yang diformat dengan betul untuk dimasukkan dalam pengepala respons HTTP.
// src/routes/login-and-set-cookie/+page.svelte
<script>
import { onMount } from "svelte";
import { auth, app } from "$lib/utilities/firebase-client";
import { goto } from "$app/navigation"; // SvelteKit's navigation for redirection
import { signInWithEmailAndPassword } from "firebase/auth";
let redirect;
let email = "";
let password = "";
onMount(() => {
// Parse the redirectTo parameter from the current URL
const urlParams = new URLSearchParams(window.location.search);
redirect = urlParams.get("redirect") || "/";
});
// this code will run after a successful login.
auth.onAuthStateChanged(async (user) => {
if (user) {
const idToken = await user.getIdToken();
console.log("In login_awith-cookie : idToken: ", idToken);
// Send token to the server to set the cookie
fetch("/api/set-cookie", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ idToken }),
});
window.alert("In with-cookie : cookie set");
goto(redirect);
}
});
async function loginWithMail() {
try {
const result = await signInWithEmailAndPassword(
auth,
email,
password,
);
} catch (error) {
window.alert("login with Mail failed" + error);
}
}
</script>
<div>
<pre class="brush:php;toolbar:false">// src/routes/api/set-cookie/+server.js
import admin from 'firebase-admin';
import cookie from 'cookie';
export async function POST({ request }) {
const { idToken } = await request.json();
try {
// Verify the token with Firebase Admin SDK
const decodedToken = await admin.auth().verifyIdToken(idToken);
// Use the cookie.serialize method to create a 'Set-Cookie' header for inclusion in the POST
// response. This will instruct the browser to create a cookie called 'idToken' with the value of idToken
// that will be incorporated in all subsequent browser communication requests to pages on this domain.
const headers = {
'Set-Cookie': cookie.serialize('idToken', idToken, {
httpOnly: true, // Ensures the cookie is only accessible by the web server
secure: true, // Ensures the cookie is only sent over HTTPS
sameSite: 'None', // Allows the cookie to be sent in cross-site requests
maxAge: 60 * 60, // 1 hour (same as Firebase ID token expiry)
path: '/' // Ensures the cookie is sent with every request, regardless of the path.
})
};
let response = new Response('Set cookie from login', {
status: 200,
headers,
body: { message: 'Cookie set successfully' } // Optional message
});
console.log("Cookie set")
return response;
} catch (err) {
console.error("Error in login server function: ", err);
let response = new Response('Set cookie from login', {
status: 401,
body: { message: 'Unauthorized' } // Optional message
});
return response;
}
};
Tidak perlu halaman log keluar "log keluar-dan keluarkan-kuki". Menetapkan kuki baharu akan menimpa mana-mana versi lama dengan nama yang sama.
Akaun Perkhidmatan untuk projek ialah objek yang dibungkus dengan kunci selamat dan maklumat "pemilik" (seperti projectId projek). Apabila fail "page.server.js" dijalankan, salinan Akaun Perkhidmatan yang dibenamkan di dalamnya dibentangkan kepada Google. Jika kedua-duanya sepadan, fail pelayan disahkan.
Berikut ialah prosedur untuk:
// src/routes/products-maintenance-sv/+page.svelte
<script>
import { auth } from "$lib/utilities/firebase-client";
import { onMount } from "svelte";
import { goto } from "$app/navigation";
onMount(async () => {
if (!auth.currentUser) {
// Redirect to login if not authenticated, with a redirect parameter
goto("/login?redirect=/products-maintenance-sv");
return;
}
try {
// Fetch the ID token directly
const idToken = await auth.currentUser.getIdToken();
window.alert("idToken:" + JSON.stringify(idToken));
} catch (error) {
window.alert("Error retrieving ID token:", error);
}
});
</script>
Ini adalah satu lagi contoh mekanisme perlindungan yang diterangkan sebelum ini dalam Post 3.3 untuk menghalang anda daripada mendedahkan fail secara tidak sengaja dalam repositori Git. Bagi pengguna Windows, pendekatan yang lebih selamat ialah mencipta pembolehubah persekitaran Windows GOOGLE_APPLICATION_CREDENTIAL untuk menyediakan rujukan utama.
Untuk menjalankan prosedur "log masuk pelayan", kod page.server.js anda memerlukan akses kepada API pentadbir Firebase. Anda mendapat ini dengan memasang "firebase-admin" dalam projek anda:
// Set a secure, HTTP-only cookie with the `idToken` token
const headers = {
'Set-Cookie': cookie.serialize('idToken', idToken, {
httpOnly: true
})
};
let response = new Response('Set cookie from server', {
status: 200,
headers,
body: { message: 'Cookie set successfully' } // Optional message
});
return response;
Kini anda boleh membuat rujukan pentadbir dalam kod anda dengan:
// client-side +page.svelte code
const idToken = await user.getIdToken();
// Send token to the server to set the cookie
fetch("/api/login", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ idToken }),
});
Perhatikan bahawa sintaks import ini berbeza daripada yang anda gunakan setakat ini - tiada kurungan kerinting di sekeliling bit "admin". Walaupun perpustakaan lain yang telah anda gunakan membenarkan anda mengimport komponen bernama, versi ini memerlukan anda mengimport keseluruhannya daripada lalai eksport pentadbir. Ini membekalkan komponen sebagai sifat seperti admin.auth(), admin.firestore(), dsb. objek pentadbir induk. Pereka bentuk perpustakaan ini telah mengambil pandangan bahawa ini adalah susunan yang lebih praktikal dalam situasi ini.
Apabila menggunakan import lalai anda boleh memanggil objek induk yang diimport apa sahaja yang anda suka (cth, anda mungkin memanggilnya myFirebaseAdmin dan bukannya admin). Bandingkan susunan ini dengan pendekatan eksport bernama fail lib/utilities/firebase-config yang anda buat sebelum ini
Di sinilah anda akhirnya turun ke perkara-perkara kecil menggunakan API Pentadbir Firestore untuk mengakses bahagian pelayan pangkalan data Firestore.
Mula-mula, anda menggunakan kunci Akaun Perkhidmatan anda untuk "memulakan" apl anda dan dengan itu mendapat kebenaran untuk mencipta objek adminDb yang diperlukan untuk menggunakan API Pentadbiran (sama seperti yang anda perlukan db untuk API Klien). Kemudian anda perlu mendapatkan idToken anda daripada kuki dan mengekstrak daripada mana-mana kandungan pengguna yang mungkin anda perlukan dalam panggilan Firestore anda. Pada ketika ini, anda akhirnya bebas untuk mengekodkan panggilan ini menggunakan API Pentadbir Firestore.
Salin kod yang disenaraikan di bawah ke fail page.server.js baharu dalam folder src/routes/products-maintenance-sv anda. Ini ialah "versi pelayan" kod penyelenggaraan produk yang pertama kali dilihat dalam Post 3.3. Ia digunakan di sana untuk menunjukkan cara kod sebelah pelayan yang cuba menggunakan API Klien Firestore akan gagal apabila koleksi yang mereka tangani tertakluk pada peraturan pangkalan data Firestore. Versi baharu ini mendapat manfaat daripada:
// src/routes/products-maintenance-sv/+page.svelte
<script>
import { auth } from "$lib/utilities/firebase-client";
import { onMount } from "svelte";
import { goto } from "$app/navigation";
onMount(async () => {
if (!auth.currentUser) {
// Redirect to login if not authenticated, with a redirect parameter
goto("/login?redirect=/products-maintenance-sv");
return;
}
try {
// Fetch the ID token directly
const idToken = await auth.currentUser.getIdToken();
window.alert("idToken:" + JSON.stringify(idToken));
} catch (error) {
window.alert("Error retrieving ID token:", error);
}
});
</script>
Perhatikan cara aneh kod membina medan e-mel pengguna
// Set a secure, HTTP-only cookie with the `idToken` token
const headers = {
'Set-Cookie': cookie.serialize('idToken', idToken, {
httpOnly: true
})
};
let response = new Response('Set cookie from server', {
status: 200,
headers,
body: { message: 'Cookie set successfully' } // Optional message
});
return response;
Nama kaedah verifyIdToken mungkin membuatkan anda tertanya-tanya sama ada ini cuba mengesahkan pengguna anda sekali lagi. Jangan risau - tidak. Ia hanya melakukan semakan keselamatan pada "tandatangan" tertanam token untuk memastikan dirinya sendiri bahawa ia tidak diganggu dan belum tamat tempoh.
DecodedToken yang dibuat oleh verifyIdToken ialah objek ringkas yang mengandungi sifat e-mel dan nama pengguna dll untuk pengguna anda yang disahkan. Kod Firestore berikutnya tidak menggunakan mana-mana daripada ini, tetapi saya pasti anda boleh membayangkan dengan mudah bagaimana ia boleh melakukannya.
Saya cadangkan anda menggunakan pendekatan "boiler-plate" sekali lagi apabila pengekodan panggilan API Admin - gunakan chatGPT untuk menukar kod pelanggan yang didokumenkan dalam Post 10.1 jika perlu.
Sekarang gantikan kandungan fail src/routes/products-maintenance-sv/ page.svelte yang anda buat sebelum ini dengan kod yang ditunjukkan di bawah. Ini akan menyediakan bahagian hadapan pelanggan kepada fail products-maintenance-sv/ page.server.js:
// src/routes/products-maintenance-sv/ page.svelte
<skrip>
import { onMount } daripada "svelte";
import { auth } daripada "$lib/utilities/firebase-client";
import { goto } daripada "$app/navigation";
import { productNumberIsNumeric } daripada "$lib/utilities/productNumberIsNumeric";
// Letakkan semakan pada perubahan keadaan pengesahan di dalam panggilan balik onAuthStateChanged di dalam onMount. Ini nampaknya
// pelik tetapi nampaknya satu-satunya cara untuk menyelesaikan aktiviti sebelah pelayan dan auth.currentUser menjadi stabil
// negeri. Ini bukan isu di sisi pelanggan versi "mesra peraturan" tetapi menjadi masalah sejurus selepas itu
// sebagai fail page.server.js dengan actions() telah ditambahkan.
onMount(async () => {
auth.onAuthStateChanged(async (pengguna) => {
jika (!auth.currentUser) {
// Ubah hala ke log masuk jika tidak disahkan. Parameter memberitahu log masuk bagaimana untuk kembali ke sini
goto("/login-and-set-cookie?redirect=/products-maintenance-sv");
}
});
});
biarkan productNumber;
biarkan productDetails;
biarkan productNumberClass = "productNumber";
biarkan submitButtonClass = "submitButton";
borang surat kebenaran eksport;
</skrip>
<form method="POST">
<label>
Nombor Produk
<masukan
bind:value={productNumber}
name="productNumber"
>
<p>Untuk menjalankan ini dalam pelayan pembangun anda, mulakan dengan log keluar menggunakan http://localhost:5173/logout. Kemudian jalankan http://localhost:5173/products-maintenance-sv. Ini akan menjemput anda untuk log masuk pada halaman log masuk-dan-set-kuki. </p>
<p>Setelah anda berjaya melog masuk, anda akan melihat borang biasa yang menjemput anda untuk mencipta produk baharu. </p>
<p>Pada ketika ini, halaman log masuk-dan-set-kuki sepatutnya telah menetapkan kuki idToken dengan selamat dalam penyemak imbas anda. Apabila anda memasukkan data dan menyerahkan borang, kawalan akan dihantar ke kod sebelah pelayan dalam products-maintenance-sv/ page.server.js. Ini mengesahkan dirinya sendiri dengan membentangkan kod perkhidmatan yang dibina ke dalam projek anda dan kemudian mengambil idToken daripada pengepala dan data inputnya daripada objek borang dalam permintaan Sveltekit. Kod itu tidak akan melakukan apa-apa yang berguna dengan data pengguna yang tersedia dalam idToken tetapi mesej log yang memaparkan nilai userEmail akan dipaparkan dalam terminal VSCode. Akhir sekali, kod Pentadbir Firestore akan menambah produk baharu pada koleksi pangkalan data produk.</p>
<p>Anda boleh mengesahkan bahawa kemas kini telah berjaya digunakan dengan menjalankan halaman http://localhost:5173/products-display-rf lama.</p>
<p>Perhatikan bahawa selepas borang diserahkan, ia memaparkan mesej pengesahan dan mengosongkan medan inputnya. "Segar semula borang" ialah tindakan lalai Javascript selepas penyerahan borang. </p><p>Anda mungkin tertanya-tanya bagaimana halaman halaman http://localhost:5173/products-display-rf berfungsi apabila ia masih menjalankan Firestore <strong>Klien</strong> bahagian pelayan kod API dengan peraturan pengesahan Firestore yang ditetapkan pada koleksi produk. Perbezaannya ialah peraturan ini hanya digunakan untuk menulis. Produk-paparan-rfcode hanya membaca dokumen. </p>
<p>Dalam amalan, saya berpendapat bahawa jika anda bimbang untuk mengelakkan kekeliruan dan memutuskan untuk mencipta produk-paparan-sv versi produk-paparan-sv anda ingin menggunakan Firestore <strong>Pentadbir</strong> panggilan API sepanjang . Walau bagaimanapun, ingat bahawa anda perlu bermula dengan membentangkan bukti kelayakan Akaun Perkhidmatan anda untuk memulakan Aplikasi.</p>
<h3>
3. Rumusan
</h3>
<p>Ini adalah siaran yang panjang dan akan memanjangkan Javascript anda ke had. Jika anda masih bersama saya pada ketika ini - syabas. Sungguh, syabas - anda telah mempamerkan kegigihan yang luar biasa! </p>
<p>Teknik "sebelah pelanggan" yang diperkenalkan oleh siaran sebelumnya adalah kegembiraan untuk digunakan, tetapi saya harap anda akan menghargai kelebihan keselamatan dan kelajuan pengaturan sisi pelayan. Dengan pengalaman, pembangunan kod sebelah pelayan akan menjadi semudah dan semula jadi seperti kerja sebelah pelanggan.</p>
<p>Tetapi masih ada satu perkara lagi yang perlu dilakukan. Walaupun anda kini telah membangunkan apl web dengan banyak halaman yang berjalan dengan baik dalam pelayan pembangun anda, satu pun daripada ini belum kelihatan di web.</p>
<p>Siaran seterusnya memberitahu anda cara anda "membina" dan menggunakan apl web anda pada Google AppEngine dan dengan itu mengeluarkannya kepada orang ramai yang tidak sabar-sabar. Ini akan menjadi detik yang besar! </p>
<p>Saya harap anda masih mempunyai tenaga untuk membaca dan mengetahui perkara yang perlu anda lakukan. Ia tidak terlalu sukar.</p>
<h3>
Postscript: Apabila berlaku masalah - melihat Pengepala dalam Inspektor
</h3>
<p>Sebenarnya, bilangan perkara yang boleh menjadi salah untuk anda dalam bahagian ini mungkin menghampiri yang tidak terhingga. Cuba untuk tidak terlalu panik dan perhatikan dengan teliti struktur pemfailan projek anda. Terlalu mudah untuk memasukkan kod yang betul ke dalam fail yang salah, atau fail yang betul ke dalam folder yang salah. Selain itu, anda mungkin mendapati ia berguna untuk kerap "membersihkan tanah" dengan membunuh dan memulakan semula sesi terminal anda. Sekurang-kurangnya, ini memberi anda rekod bersih apabila mencari punca awal urutan ralat.</p>
<p>Tetapi, memandangkan anda kini bermain dengan pengepala dan kuki, anda juga akan mendapati ia berguna untuk mengetahui bahawa alat Inspektor penyemak imbas boleh memberi anda cerapan visual tentang perkara ini. Pemeriksa boleh <strong>menunjukkan</strong> kepada anda kuki yang dibenamkan dalam pengepala permintaan halaman.</p><p>Untuk melihat kemudahan ini beraksi, mula-mula pastikan anda log keluar pada sistem langsung dengan https://myLiveUrl/logout (di mana myLiveUrl ialah alamat aplikasi web anda yang digunakan) . Kemudian jalankan halaman products-maintenance=sv di https://https://myLiveUrl/products-maintenance-sv. Dapatkan diri anda log masuk, buka Inspektor pada borang "masukkan produk baharu" dan klik pada tab "Rangkaian". Ini kini memaparkan senarai permintaan rangkaian yang dibuat oleh halaman.</p>
<p>Sekarang gunakan apl web untuk memasukkan Produk baharu dan perhatikan cara senarai "permintaan" dimuat semula. Ini adalah permintaan rangkaian yang diperlukan untuk melaksanakan kemas kini mudah itu - senarai yang sangat panjang! Menatal kembali ke bahagian atas senarai ini, anda harus mencari entri untuk halaman produk-penyelenggaraan-sv anda. Jika anda mengklik pada ini, panel di sebelah kanan senarai permintaan harus memaparkan butiran penuh kedua-dua respons dan pengepala permintaan untuk transaksi. Tangkapan skrin di bawah menunjukkan kuki yang dibenamkan dalam pengepala permintaan.</p>
<p><img src="https://img.php.cn/upload/article/000/000/000/173301818045981.jpg" alt="NgSysV.A Serious Svelte InfoSys: A Client-Server Version"></p>
Atas ialah kandungan terperinci NgSysV.A Serius Svelte InfoSys: Versi Pelayan-Pelanggan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
