#JSP とサーブレットの違いは何ですか? (推奨される學(xué)習(xí): Java の頻繁な會議テストの質(zhì)問 )

JSP がサービスになる JSP コードを認(rèn)識すると、Web コンテナは JSP コードを Java クラスにコンパイルします。 JVM)

jsp はページ表示に優(yōu)れ、サーブレットはロジック制御に優(yōu)れています。

サーブレットには組み込みオブジェクトがありません。Jsp の組み込みオブジェクトは、HttpServletRequest オブジェクト、HttpServletResponse オブジェクト、および HttpServlet オブジェクトを通じて取得する必要があります。

Jsp はサーブレットを簡略化したものです。Jsp を使用する場合は、プログラマがクライアントに出力する必要がある內(nèi)容だけを完成させる必要があります。Jsp 內(nèi)の Java スクリプトをクラスに埋め込む方法は、Jsp コンテナーによって完了します。サーブレットは完全な Java クラスであり、このクラスの Service メソッドはクライアントへの応答を生成するために使用されます。

jsp の組み込みオブジェクトとは何ですか?機(jī)能は何ですか?

JSP には 9 つの組み込みオブジェクトがあります:

request: GET または POST リクエストからのパラメータを含むクライアントのリクエストをカプセル化します。 # #response: クライアントへのサーバーの応答をカプセル化します;

pageContext: このオブジェクトを通じて他のオブジェクトを取得できます;

session: ユーザー セッションをカプセル化するオブジェクト;

application: サーバーをカプセル化します 実行環(huán)境のオブジェクト;

out: 出力サーバー応答の出力ストリーム オブジェクト;

config: Web アプリケーションの構(gòu)成オブジェクト;

page: JSP ページ自體 (プログラム內(nèi)の Java this に相當(dāng));

Exception: ページによってスローされた例外をカプセル化するオブジェクト。

JSP の 4 つのスコープについて教えてください。

JSP の 4 つのスコープには、ページ、リクエスト、セッション、アプリケーションが含まれます。特に:

page は、ページと屬性に関連するオブジェクトを表します。

request は、Web クライアントによって発行されたリクエストに関連するオブジェクトと屬性を表します。リクエストは複數(shù)のページにまたがり、複數(shù)の Web コンポーネントが関與する場合があり、ページに表示する必要がある一時データをこのスコープに配置できます。

session は、ユーザーとサーバーによって確立されたセッションに関連するオブジェクトと屬性を表します。ユーザーに関連するデータは、ユーザー自身のセッションに配置する必要があります。

application は、Web アプリケーション全體に関連するオブジェクトとプロパティを表します?；镜膜?、複數(shù)のページ、リクエスト、セッションを含む Web アプリケーション全體にわたるグローバル スコープです。

セッションとクッキーの違いは何ですか?

HTTP プロトコルはステートレス プロトコルであるため、サーバーがユーザーのステータスを記録する必要がある場合、特定のユーザーを識別するための何らかのメカニズムを使用する必要があります。このメカニズムはセッションです。ショッピングなどの一般的なシナリオCar では、注文ボタンをクリックすると、HTTP プロトコルはステートレスであるため、どのユーザーが操作しているかがわからないため、サーバーはユーザーを識別し、ユーザーを追跡するために、特定のユーザーに対して特定のセッションを作成する必要があります。ショッピングカートに何冊の本が入っているかがわかります。

このセッションはサーバー側(cè)に保存され、一意の識別子を持ちます。サーバー側(cè)でセッションを保存するには、メモリ、データベース、ファイルなど、さまざまな方法があります。

クラスタリング時にはセッション転送も考慮する必要があります。大規(guī)模な Web サイトでは、通常、ユーザー セッションを保存するための専用のセッション サーバー クラスターが存在します。このとき、セッション情報はメモリに配置され、一部のキャッシュが使用されます。このようなサービスMemcached としてセッションを保存するために使用されます。

サーバーが特定の顧客をどのように識別するかについて考えてみませんか?

この時點(diǎn)で Cookie が表示されます。 HTTP リクエストが行われるたびに、クライアントは対応する Cookie 情報をサーバーに送信します。実際、ほとんどのアプリケーションはセッション追跡を?qū)g裝するために Cookie を使用します。初めてセッションが作成されると、サーバーは HTTP プロトコルでクライアントにセッション ID を Cookie に記録する必要があることを伝えます。これはセッションごとに記録されます。セッション ID がサーバーに送信され、あなたが誰であるかがわかります。

誰かが質(zhì)問しました。クライアントのブラウザで Cookie が無効になっている場合はどうすればよいですか?

通常、この場合、URL 書き換えと呼ばれるテクノロジがセッション追跡に使用されます。つまり、HTTP インタラクションごとに、sid=xxxxx などのパラメータが URL に追加されます。これを使用してユーザーを識別します。

Cookie は実際にいくつかのユーザーフレンドリーなシナリオで使用できます。Web サイトに一度ログインした後、次回ログインするときにアカウントを再度入力したくないと想像してください。やるべきですか？

この情報は Cookie に書き込むことができ、Web サイトにアクセスすると、Web ページのスクリプトがこの情報を読み取り、ユーザー名を自動的に入力するため、ユーザーの利便性が高まります。クッキー名の由來でもある、ユーザーへのちょっとした甘さ。

要約すると:

セッションはユーザーのステータスを追跡するためにサーバー側(cè)に保存されるデータ構(gòu)造であり、このデータはクラスター、データベース、ファイル內(nèi);

Cookie はクライアントがユーザー情報を保存するためのメカニズムであり、ユーザー情報の一部を記録するために使用され、Session の実裝方法でもあります。

セッションの仕組みを教えてください。

実際、セッションはサーバー上に存在するハッシュ テーブルに似たファイルです。必要な情報はそこに保存されており、必要なときにすぐに取り出すことができます。

これは大きな地図に似ています。內(nèi)部のキーにはユーザーのセッション ID が格納されます。ユーザーはサーバーにリクエストを送信するときにこのセッション ID を持ちます。このとき、対応する値をそこから抽出することができます。

クライアントが Cookie を無効にしても、セッションは引き続き使用できますか?

Cookie と Session は一般に 2 つの獨(dú)立したものであると考えられており、Session はサーバー側(cè)で狀態(tài)を維持するソリューションを使用し、Cookie はクライアント側(cè)で狀態(tài)を維持するソリューションを使用します。

しかし、Cookie を無効にするとセッションを取得できないのはなぜでしょうか?

セッションはセッション ID を使用して現(xiàn)在の會話に対応するサーバー セッションを決定し、セッション ID は Cookie を介して渡されるため、Cookie を無効にすることはセッション ID を失うことと同等であり、取得できなくなります。セッション。

ユーザーが Cookie をオフにするときにセッションを使用することを想定した実裝方法は次のとおりです。

php.ini 設(shè)定ファイルで "session.use_trans_sid = 1" を設(shè)定します。 」、またはコンパイル時に「--enable-trans-sid」オプションをオンにして、PHP がページ間でセッション ID を自動的に渡すようにします。

URL を通じて値を手動で渡し、非表示のフォームを通じてセッション ID を渡します。

セッション ID をファイル、データベースなどに保存し、クロスページ プロセス中に手動で呼び出します。

Spring MVC と Struts の違いは何ですか?

インターセプト メカニズムの違い

Struts2 はクラスレベルのインターセプトです。各リクエストはアクションを作成します。Spring と統(tǒng)合する場合、Struts2 ActionBeanインジェクションスコープはプロトタイプモードであり、リクエストデータはセッターとゲッターを通じてプロパティに注入されます。

Struts2では、Actionはリクエストとレスポンスのコンテキストに相當(dāng)し、パラメータを受け取る際には屬性を介して受け取ることができ、屬性パラメータが複數(shù)のメソッドで共有されることがわかります。

Struts2 の Action のメソッドは URL に対応できますが、そのクラス屬性はすべてのメソッドで共有されます。これは、そのメソッドを識別するためにアノテーションや他のメソッドを使用することは不可能であることを意味します。複數(shù)のインスタンスとして設(shè)計されています。

SpringMVC はメソッドレベルのインターセプトであり、1 つのメソッドがリクエスト コンテキストに対応するため、メソッドは基本的に獨(dú)立しており、リクエスト データとレスポンス データに排他的にアクセスできます。各メソッドは同時に URL に対応しており、メソッドに固有のパラメータの受け渡しが直接メソッドに挿入されます。処理結(jié)果はModeMapを通じてフレームワークに返されます。

Spring 統(tǒng)合中、SpringMVC のコントローラー Bean はデフォルトでシングルトン モードになるため、デフォルトでは、すべてのリクエストに対してコントローラーが 1 つだけ作成されます。共有屬性は存在しないため、スレッドセーフです。デフォルトのスコープを変更するには、@Scope アノテーションの変更を追加する必要があります。

Struts2には獨(dú)自のインターセプタ機(jī)構(gòu)があり、SpringMVCでは獨(dú)自のAopメソッドを使用しているため、Struts2の設(shè)定ファイルの量はSpringMVCに比べて多くなります。

基盤となるフレームワークの違い

Struts2 は Filter (StrutsPrepareAndExecuteFilter) によって実裝され、SpringMVC (DispatcherServlet) は Servlet によって実裝されます。フィルタはコンテナの起動後に初期化されますが、サーブレットよりも後で、サービスの停止後にクラッシュします。サーブレットは、フィルターが呼び出される前に呼び出されたときに初期化され、サービスの停止後に破棄されます。

パフォーマンスの側(cè)面

Struts2 はクラスレベルのインターセプトであり、各リクエストはインスタンスの新しいアクションに対応し、すべての屬性値の注入をロードする必要があります。 SpringMVC のメソッドベースのインターセプトにより、シングルトン モードの Bean インジェクションは 1 回ロードされます。したがって、SpringMVC の開発効率とパフォーマンスは Struts2 よりも高くなります。

構(gòu)成の側(cè)面

spring MVC と Spring はシームレスです。このプロジェクトの管理とセキュリティも Struts2 よりも高くなっています。

SQL インジェクションを回避するにはどうすればよいですか?

PreparedStatement (シンプルで効果的なメソッド)

正規(guī)表現(xiàn)を使用して受信パラメータをフィルタリングする

文字列フィルタリング

JSP で呼び出されるこの関數(shù)は、次のことを確認(rèn)します。不正な文字が含まれています

JSPページ判定コード

XSS攻撃とは何ですか?またその回避方法はありますか?

XSS 攻撃は CSS とも呼ばれ、正式名稱は Cross Site Script (クロスサイト スクリプティング攻撃) で、攻撃者が XSS の脆弱性のある Web サイトに悪意のある HTML コードを入力するという原理です。ユーザーが Web サイトを閲覧すると、この HTML コードが自動的に実行され、攻撃の目的が達(dá)成されます。

XSS 攻撃は SQL インジェクション攻撃に似ています。SQL インジェクション攻撃では、SQL ステートメントがデータのクエリ/変更/削除のためのユーザー入力として使用されます。XSS 攻撃では、悪意のあるスクリプトが挿入され、ユーザーをターゲットにします。何らかのユーザー情報を取得します。 XSS は Web プログラムの一般的な脆弱性であり、クライアント側(cè)で使用される受動的な攻撃方法です。

XSS 防止の一般的な考え方は、入力 (および URL パラメーター) をフィルターし、出力をエンコードすることです。

CSRF 攻撃とは何ですか?また、それを回避する方法は何ですか?

CSRF (クロスサイト リクエスト フォージェリ) は、ワンクリック攻撃またはセッション ライディングとも呼ばれ、正式な中國語名はクロスサイト リクエスト フォージェリです。一般的に、攻撃者はユーザーのブラウザからのリクエストを偽造し、ユーザーがアクセスを認(rèn)証した Web サイトに送信します。これにより、標(biāo)的となる Web サイトはそれを受信し、それがユーザーの実際の操作であると誤って認(rèn)識し、コマンドを?qū)g行します。

アカウントの竊盜、送金、虛偽のメッセージの送信などによく使用されます。攻撃者は、Web サイトのリクエスト検証の脆弱性を悪用してこのような攻撃を?qū)g行しますが、Web サイトはリクエストがユーザーのブラウザからのものであることは確認(rèn)できますが、リクエストがユーザーの真の意図からのものであるかどうかを確認(rèn)することはできません。

回避方法:

1. HTTP Referer フィールドを確認(rèn)する

HTTP ヘッダーの Referer フィールドには、 HTTPリクエストの送信元アドレス。通常の狀況では、安全な制限付きページにアクセスするリクエストは同じ Web サイトから送信されます。ハッカーが CSRF

攻撃を?qū)g行したい場合、通常、ハッカーは自分の Web サイトでのみリクエストを作成できます。したがって、Referer 値を検証することで CSRF 攻撃を防御できます。

2. 認(rèn)証コードを使用する

キー操作ページに認(rèn)証コードを追加し、リクエストを受信したバックグラウンドで認(rèn)証コードを判定し、CSRF を防ぐことができます。しかし、この方法はあまりユーザーフレンドリーではありません。

3. リクエスト アドレスにトークンを追加して確認(rèn)します

CSRF 攻撃が成功する理由は、ハッカーがユーザーのリクエストを完全に偽造できるためです。ユーザー認(rèn)証情報は Cookie 內(nèi)に存在するため、ハッカーは認(rèn)証情報を知らなくても、ユーザー自身の Cookie を直接使用してセキュリティ検証を通過することができます。 CSRF に対抗する鍵は、ハッカーが偽造できない情報をリクエストに含めることと、その情報が Cookie に存在しないことです。

ランダムに生成されたトークンを HTTP リクエストのパラメーターとして追加し、サーバー側(cè)でインターセプターを設(shè)定してトークンを検証できます。リクエストにトークンが含まれていない場合、またはトークンの內(nèi)容が間違っている場合は、 CSRF攻撃によりリクエストが拒否された可能性が考えられます。

このメソッドは、Referer を確認(rèn)するより安全です。ユーザーがログインしてセッションに配置した後にトークンを生成できます。その後、トークンはリクエストごとにセッションから取り出して、リファラー內(nèi)のトークンと照合できます。比較してください。ただし、このメソッドの難しい點(diǎn)は、トークンをパラメーターの形式でリクエストに追加する方法です。

GET リクエストの場合、トークンはリクエスト アドレスに追加され、URL は http://url?csrftoken=tokenvalue になります。

POST リクエストの場合、トークンがパラメーターの形式になるように、フォームの最後に を追加します。參加をリクエストされました。

4. HTTP ヘッダーの屬性をカスタマイズして検証します

このメソッドもトークンを使用して検証します。前のメソッドとは異なり、代わりにトークンを配置します。トークンを HTTP リクエストのパラメータとして使用するには、それを HTTP ヘッダーのカスタム屬性に置きます。

XMLHttpRequest クラスを通じて、csrftoken HTTP ヘッダー屬性をこのタイプのすべてのリクエストに一度に追加し、そこにトークン値を入れることができます。

これにより、前の方法でリクエストにトークンを追加する不便さが解決されると同時に、XMLHttpRequest でリクエストされたアドレスがブラウザのアドレス バーに記録されなくなり、リファラーを通じてトークンが他の Web サイトに漏洩します。

以上がJava Web の面接でよくある質(zhì)問の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。