Form Validation

検証フォームはユーザー体験に良い影響を及ぼします.会員登録または登録の際、フォームの記入を拒否したり、会員認証を拒否したりした場合は、理由をお知らせします.そうでなければ、ユーザーは迷路に陥ることになります.
以前はフォーマット検証コードが作成されていましたが、コードは機能しませんでした.そこでフォーマット検証コードを少し修正して書き直すことにしました.
既存のフォーマット検証コードは、文字数または入力する必要がある文字のみをフロントで検証します.会員登録ボタンをクリックすると、バックグラウンドで重複認証またはパスワード検証が行われます.しかし、このプログラムは不便です.ユーザーが電子メールを入力すると、ユーザーは使用できると伝えますが、ユーザーが会員登録ボタンを押すと、再びフロントに重複する電子メールの情報が出力されるので、ユーザーは2回働かなければなりません.加えてスイッチドアを使うと、多くの分岐点があり、その後、どこが問題なのか見つけるのが難しい.
このため、電子メールや身分などの繰り返しチェックが必要であっても、フロントで入力すれば文字数や特殊文字入力などをチェックできるとともに、バックグラウンドで利用可能かどうかを知らせることができます.
検証は、入力が完了する前に行われず、入力後にイベントリスナーを介してフォーカスが移動したときに行われます.コードを書き直すときは、2つの原則を守ることにします.

関数に一度に1つのことだけをさせる

関数ロール啄み、合計

フロントエンドコードの再作成

最初は、既存のコードで各ロールに関数を分割したいだけでしたが、作成中に最初から論理を検証するのはよくありません.

会員は会員加入表を入力します.

すべて

を入力して表に加えた後、ボタンをクリックし、各表の条件に合致しなければ、その部分にエラー情報を投げ出し、該当条件を入力すれば成功情報を投げ出す.

形式の条件を満たすメールが入力されても、ユーザー名が重複している場合は、再度メールが送信されます.

この条件に基づいてコードを修正するのはよくない.コードを記述する立場では,他の関数で関数を分割する方法もますます困難になっている.だから再び近づいた.

inputでは、ユーザーがフォームにアクセスして入力し、スライドまたはマウスでフォーカスから離れ、すぐにフォームに参加してエラーまたは成功メッセージを送信することを検証します.

フロントでは、文字数やその他の条件が満たされていれば、バックグラウンドに直接データを送信して重複チェックなどを行う.

最終的には、ユーザーは条件を満たすエラーまたは成功メッセージのみを表示します.

inputRef関数の作成

function inputRef() {
  for (let i = 0; i < inputs.length; i++) {
    inputs[i].addEventListener("focusout", function (e) {
      return handleChecker(e.target);
    });
  }
}

まずformのinputを参照する関数を作成しました.したがって,焦点がずれた場合には,入力した値を検証しようとする.
イベントハンドラでイベントを送信する場合,匿名関数でhandleCheckerを単独で送信するのは,handleChecker関数が他の場所でも再利用される可能性があると考えられるため,ノードのみを受信する.
後でclickイベントを登録してhandleCheckerを再使用します.これは受信ノードとして設計されているため、イベントターゲットで現在のノードを再作成する必要はありません.

handleCheckerとロール範囲の作成

function handleChecker(node) {
  const name = node.name;
  const value = node.value;
  const checked = isTrue(name, value);
  if (checked) {
    return checkedDataBase(checked, node);
  }
  return paintMessage(checked, node);
}

handleChecker関数は、各フォーマットをisTrue関数に渡し、フロントとサーバに入力値を検証させます.その後,絵情報の役割を担うべきか,他の場所で扱うべきかを考えた.バックグラウンドでDBを問合せ、paintMessage関数を再実行するためです.HandleCheckerのキャラクターがぼやけてしまいます△名前があやふやだから.しかし、フロント検証時にpaintMessageを実行する場所を特定するのは難しいため、handleCheckerはフロント検証値の成否を伝えることにした.

isTrue関数とパスワードの検証

function isTrue(name, value) {
  if (value) {
    if (name === "password2") {
      const node = findNode(inputs, "name", "password");
      return node.value === value;
    }
    const obj = {
      email:
        /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/,
      name: /[ㄱ-ㅎ|ㅏ-ㅣ|가-힣]{2,6}$/,
      userName: /^[a-zA-Z0-9]{5,10}$/,
      password:
        /^(?=.*[a-zA-z])(?=.*[0-9])(?=.*[$`~!@$!%*#^?&\\(\\)\-_=+]).{8,}$/,
    };
    return obj[name].exec(value) ? true : false;
  }
  return false;
}

正規表現を使用して検証しました.正規表現は依然として低くて難しい.まずGoogleで検索して貼り付けます.
正規表現を参照
電子メール正規表現
パスワードの正規表現
各ノードの名前をオブジェクトに挿入し、正規表現で名前に対応する値を検証し、trueとfalseを返します.
パスワードの検証に悩んだ.最初はpwで縛って一度送ったが、これは私の論理に合わない.したがって、パスワードを検証すると、パスワードの確認に焦点を当てると、パスワードを検証し、ユーザーに成功するかどうかを教え、password 2はパスワードと値が等しいかどうかを検証し、ユーザーに成功するかどうかを教えるように設計されています.

バックエンドはどのように処理しますか?

async function checkedDataBase(bool, node) {
  const value = node.value;
  const name = node.name;

  if (name === "email" || name === "userName") {
    const response = await fetch(`/url/${name}=${value}`, {
      method: "GET",
    });

    const { exist } = await response.json();
    const checked = !exist;
    return paintMessage(checked, node, "exist");
  }

  return paintMessage(bool, node);
}

checkedDataBase関数は、フロントのchecked値がtrueの場合にのみ値を超えます.バックエンドで検証する必要があるコンテンツは、Eメールとユーザー名のみで済むため、すべての値がtrueの場合、checkedDataBase関数が実行されます.ただし、この関数がemailとuserNameの場合にのみ、fetch関数を使用して値を放出します.
fetch getを使用する場合、json値はbodyを超えていないが、原因は不明である.タイトルを設定してみて、いろいろ試してみましたが、うまくいかなかったのでパラメータ値に移動しました.

この関数は再利用できますか?

関数を作成するときに、他の場所でも再使用できるように関数をエクスポートしてみます.しかし,関数はプログラムごとに実行されるように設計されているため,再利用が困難である.関数を再利用する場合は、関数を受け入れて引数値として実行するように設計する必要があります.
ただし、このようにすると、関数が複数の引数を受け入れて実行する方法で設計され、2つの方法に違いはありません.現在、関数式プログラミングの哲学を本当に理解していない.
やってみたからには、最後までやりましょう.もう少し勉強して、関数式プログラミングの概念をここに応用して紹介すればいいです.

の最後の部分

今回Form Validationを行ったところ,設計ロジックも同様に最も重要であることが分かった.検証手順を変更したり、コードを変更したり、関数を再使用したりするだけで簡単です.
これで終わりですか?今はまだ不安です.XSSの弱点が残っているからです.フォームにscriptを入力する人がいれば、悪意のあるコードを植え込む可能性があるからです.Toast UI Editorを追加すると、NHNチームはDomPurifyというnpmパッケージを使用してこの問題を解決しました.SQL注入を試みた場合、それが防御されているかどうかは不明です.DBは完全に破壊される可能性があります.最低限の安全のためにヘルメットを着用していますが、ヘルメットは万能ではありません.
勉強中にXSSやSQL Injectionを攻撃する方法を見つけましたが、今見てもよくわかりません.自分のサイトを自分でテストしたいのですが、この方法以外に方法があるかもしれません.(また探してみる…)
YouTubeでXSSを検索すると、攻撃方法が出てきました.
7-8強XSS攻撃の概要と実践-東ビンナネットワークハッカー講座
最後に勉強中に探したYouTubeの資料を共有します.Form Validationを勉強している人に役に立つことを願っています.
[10分TECOTALK]🍎 スロープのForm Validation
[病態コード漫画]サイバー攻撃と防御と狂気ウサギ(セキュリティ、パラメータ改ざん、XSS、SQL入力、パスワード暗号化)
コード全体が襟元にあります