2.0.2がリリースされていたのでバージョンアップしました。セキュリティの脆弱性によるバージョンアップのようです。
Web日記支援システムtDiaryにおいて、クロスサイト・リクエスト・フォージェリ(CSRF)の問題が発見されました。
CSRF?うーん知りませんでした。恥ずかしい。 http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html
ログインセッションを利用して正規ユーザに処理を行わせる。 怖っ!(゜Д゜;)
JavaとC#どっちが優れているのか?とかそういうありふれた話題では なく、なんとなく思ったので書いてみます。
Javaだとメソッドにthrowsを書いていたものが.NETではない。 JavaでいうRuntimeException扱いになっていて(厳密にはSystemExceptionとApplicationExceptionで分かれているけど扱いは同じ)、コードがすっきり する点ではいい一方、どんな例外が発生するのかっていうのが ドキュメントを見る、もしくはメソッドの中身を見ないと分からないっていうのは どうなのかなあっと思ってしまいました。
例えばコードを見たときに
public User login(String userName, String userPassword) throws UserAuthorityException {
っていう場合、ああ失敗したときはUserAuthorityExceptionがthrowされてくるのねっていうのが 視覚的に分かり、かつその上位層ではcatchする義務が発生する一方
public User login(String userName, String userPassword) {
っていう場合では、メソッドの中身のコードを見ない限り、どういうふうにエラー処理をしないといけないのか分からない。 シンプルに作られているのであれば、それを発見することも簡単ですけど、やっぱり面倒くさい。
Javaの場合は、アプリケーションで処理しない(IOException, SQLException...)ものに関してはRuntimeExceptionを継承した例外を投げてお終いっていうのが基本。まあこれはこれで面倒くさい。 でも最近のフレームワークはアプリケーションで処理しないものは大体変換してくれてるからこちら側が意識する必要はあまりない気がします。
.NETでは、どういう方法で解決するのがいいのか。ふとそんなことを思ってしまった自分でした。
当たり前のことしか思い浮かびませんでしたorz
まずはシンプルにつくることに間違いはないです。
たとえばIOrderDaoインターフェースのInsertメソッドを参照させるには
/// <summary> /// <see cref="Hoge.Dao.IOrderDao.Insert" /> /// </summary>