3

インデックス ファイルでは、通常、ファイルの先頭に<cfparam>、URL、フォーム、またはその他の場所から取得される変数を出力します。しかし、多くのボットがwww.example.com/survey/index.cfm?nPageNumber=-1のような cfparam を意味するようなメッセージを送っています。

<cfparam name="request.parameters.nPageNumber" default="1" type="numeric" />

ボットがクエリ文字列に入れているナンセンスのために失敗します。

cfparams を次のように記述しなければならないことがますます増えています。

<cfif structKeyExists(request.parameters,"nPageNumber") AND isNumeric(request.parameters.nPageNumber)>
    <cfparam name="request.parameters.nPageNumber" default="1" type="numeric" />
<cfelse>
    <cfset request.parameters.nPageNumber = 1>
</cfif>

これで問題は解決しますが、この解決策が最善/最も効率的ではないと感じずにはいられません。私はcfparam正しく使用していますか、それともこれを行うためのより良い方法はありますか?

4

1 に答える 1

5

変数の存在を確認することと、その値を検証することは、2つの別個のタスクです。

の場合URL、Form存在コードは次のようになります。

<cfparam name="URL.nPageNumber" default="1" type="string">

そこの使用はtype、値が構造体やクエリなど、本当に奇妙なことが起こらないようにするためだけのものです。ユーザーにとって500ではなく、適切なエラーが必要なため、この時点で具体的にする必要はありません。 。

値が存在することを確認したら、値を検証する必要があります。

<cfif isNumeric(URL.nPageNumber) EQ false OR URL.nPageNumber LT 1 OR URL.nPageNumber GT Variables.MaxPages>
    <cfset ArrayAppend(Variables.ErrorArray, "Incorrect page number requested.")>
</cfif>

値を適切なものに強制することもできますが、ロバストネス原則に対する反論については、火星のヘッドセットを参照してください。

「正気の何かを表示する」の代わりにエラーメッセージを提供すると、ユーザーが何か間違ったことをしていることをユーザーに通知します。つまり、まだ使用していない場合は、正規のURLを使用する必要はありません（ただし、そうする必要があります）。

はい、それはもっと仕事です。すべての抽象化を考案することはできますが、生のレベルでは、それを実行してcfparam検証する必要があります。

ボットや、明らかにハッキングやプロービングであるリクエストなど、友好的な応答を行う必要がない状況では、「400」応答コードを提供する追加のオプションがあります。w3cは、応答を「要求の構文が間違っているか、本質的に満たすことができなかった」と定義しています。ここで、「構文が正しくないため、サーバーは要求を理解できませんでした。クライアントは、変更せずに要求を繰り返すべきではありません。」ここ。

于 2012-10-08T10:15:45.980 に答える