Pengesahan URL atau: Bagaimana Saya Belajar Berhenti Membimbangkan dan Sayangi Pengguna

Ada masanya untuk setiap pembangun web apabila mereka perlu melakukan beberapa jenis pengesahan input. Borang bukanlah catatan blog di mana pengguna boleh berpuisi tentang kecintaan mereka terhadap Yahoo Mail dalam medan e-mel. Akhirnya, perlu ada had bilangan perkataan, semakan untuk aksara tertentu dan teknik pengesahan mudah yang menghalang pengguna daripada menghantar permintaan POST sampah.

Namun, bagaimana jika anda perlu mengesahkan URL? Dan untuk menambah lapisan lain kepada masalah, bagaimana jika anda hanya mahu nama hos URL, tiada laluan, tiada protokol, hanya "dubya dubya dubya dot" (www.) dan .com.

Mari kita mulakan dengan mengetahui sama ada URL ialah URL. Pautan memerlukan domain peringkat kedua dan teratas, masing-masing walmart dan .com dalam walmart.com dan skema (https://). Tanpa bahagian ini, pautan tidak dipautkan kepada apa-apa dan menjadi tidak berbeza daripada baris teks.

Tetapi sekarang setelah kami mengetahui bahagian URL, kami mencapai persimpangan atau laluan pembangunan. Sekiranya pengesahan mengehadkan pengguna di medan atau membersihkan input pengguna apabila data dihantar ke pelayan?

Terdapat kebaikan dan kekurangan dalam kedua-dua pilihan:

---

Pengesahan Sebelum Penyerahan

Jika anda mengehadkan pengguna daripada menyerahkan URL yang tidak sah, ia membolehkan anda mengambil data dengan mudah di bahagian pelayan tanpa sebarang kerja tambahan dengan memaksa pengguna menyerahkan struktur input tepat yang anda perlukan. Dalam kes ini, atribut corak untuk elemen input digabungkan dengan beberapa regex akan membenarkan beberapa pengesahan medan lama yang baik.

Berikut ialah contoh pendekatan ini:

<input type="text" pattern="https?://.*"

Walau bagaimanapun, ia datang dengan kelemahan menyekat pengguna. Ia memerlukan pengguna untuk mempunyai bahagian tertentu untuk input mereka dan jika anda hanya perlu ada .com, maka corak regex yang panjang mungkin berlebihan.

---

Pengesahan Selepas Penyerahan

Sebaliknya, jika anda memilih untuk membersihkan data selepas pengguna menyerahkannya, ia membenarkan pengguna menaip apa sahaja dan membenarkan pelayan memutuskan perkara yang perlu dilakukan dengan data tersebut. Pembina URL Javascript melakukan pengesahan untuk anda, mengembalikan TypeError jika input tidak sah dan juga membenarkan anda mengekstrak bahagian tertentu URL seperti asal atau nama hos.

Berikut ialah contoh pendekatan ini:

export const formatWebsiteAfterDomain = (website: string): string => {
  if (!website.trim().length) {
    return '';
  }
  const regEx = /:\/\//;
  const websiteTrimmed = website.trim();
  const hasProtocol = regEx.exec(websiteTrimmed);
  const updatedWebsite = hasProtocol
    ? websiteTrimmed
    : `https://${websiteTrimmed}`;

  try {
    const url = new URL(updatedWebsite);
    return hasProtocol ? url.origin : url.origin.replace('https://', '');
  } catch (_err) {
    return websiteTrimmed;
  }
};

Walau bagaimanapun, kerana anda memberi pengguna begitu banyak kebebasan dalam input mereka, ia memerlukan beberapa kompromi dalam perkara yang pelayan lakukan dengan data. Jika pengguna meletakkan URL yang tidak sah, apakah yang anda lakukan dengannya? Adakah anda menggunakan respons TypeError dan memberitahu pengguna atau adakah anda hanya membenarkan pelayan menggunakan apa yang dihantar oleh pengguna? Selain itu, pembina URL mengesahkan input dengan menyemak sama ada terdapat skema (https:// atau http://), yang mungkin terlalu sedikit pengesahan untuk kegunaan anda.

---

Akhirnya, laluan yang diambil bergantung pada kes tepi khusus masalah anda. Gabungan kedua-dua penyelesaian mungkin yang paling komprehensif dan serba boleh atau salah satu daripada pilihan mungkin cukup. Pengguna boleh memasukkan sebarang input dan penyelesaian anda akan ditentukan pada jumlah kebebasan yang anda sanggup berikan kepada pengguna. Walau bagaimanapun, perkara yang kekal universal ialah keupayaan pengguna untuk menaip apa sahaja akan sentiasa memaksa pengguna dan pembangun untuk berkompromi (selalunya pembangun mendapat corak input tertentu dan pengguna dapat menggunakan aplikasi mereka).

Tetapi memandangkan keistimewaan input pengguna adalah kekal, akan sentiasa ada pembangun yang menolak penyelesaian secara tergesa-gesa supaya apl web mereka tidak rosak apabila pengguna cuba menampal imej dalam medan URL sesuatu borang.

Atas ialah kandungan terperinci Pengesahan URL atau: Bagaimana Saya Belajar Berhenti Membimbangkan dan Sayangi Pengguna. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!