Cross site request forgeries(以下、CSRFと略す)とは、Webサイトにスクリプトや自動転送(HTTPリダイレクト)を実装することにより、
@ContextConfigurationで読込先の指定方法を理解することによって、共通のspring設定ファイルとイレギュラー的に使用するspring設定ファイルを明示的に分けることが出来ます。 classpath指定した場合の参照先@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations="classpath:servlet-context-test.xml") public class ExampleServoceTest { @Autowired private ExampleServoce service; @Test public void testService() { String ret = service.find(""); assertEquals("test dao!!", ret
SpringSecurityを利用するとControllerからもこんな感じで、簡単に主体情報を取得できます。 SecurityContextHolder.getContext().getAuthentication().getPrincipal(); ただし、この実装を利用した場合、 ユニットテスト時は当然主体情報を取得できません。 認証情報がありませんので。。。 そのためテストをする場合は、 その認証情報を以下のように、 TestingAuthenticationTokenとしてSecurityContextHolderに格納してあげると良いとのこと。 // User情報は通常格納する主体情報を利用します。 // SpringSecurityを利用する場合は大体UserDetailsを継承しているかと。 User user = new User() {}; // Test用の認証Tok
この記事は STBBS.NET Blogで掲載された記事を2013年3月に移動したものです テストケースくらいはなるべく特定のフレームワークに依存させたくないという気持ちはあるものの、さすがに Hibernateやらといったヘヴィな奴をインスタンス化する長い道のりを手でコーディングしたり、単一責任の原則に基づいて真面目に分割されたコンポーネント群のワイヤリングを手でコーディングしたりするのはかなり厳しいものがあるので、そこは目をつぶってテストケースもやはり Springの助けを借りて実装するのが現実的だ。 なお JUnitと Springを連携させるには、spring.jarの他に spring-test.jar が必要となる。 Eclipseについてる JUnitを捨てる ※本記事執筆当時の情報です。今の Eclipseには十分新しい JUnit (JUnit 4)が搭載されています。
Web層ではSpring XMLの設定が下の層に比べて冗長になりがちで、おそらくその価値も低い傾向にあるので、わずかな量のXMLで済むというのは素晴らしいニュースです。コントローラは、view名やフォームオブジェクト名、バリデータ型など多数のプロパティを保持しますが、その目的は依存性注入よりも設定です。そうした設定を効率的に管理する方法として、bean定義の継承や、あまり頻繁に変更しないプロパティの設定回避があります。しかし、経験から申し上げると、多数のデベロッパがそうした方法をとらないので、結果として必要以上のXMLとなってしまうのです。ですから、@Controllerと@AutowiredはWeb層の設定に非常に好ましい効果を上げられるのです。 シリーズ第2弾でこの議論を引き継ぎ、Web層向けのSpring 2.5アノテーションを一通り見て回ります。こうしたアノテーションは非公式に@M
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く