2011年12月15日木曜日

Jersey Client 利用時の文字化け on CentOS5

Sakura VPS 上でJersey Client API を使った、
JSONを取得して、加工、受け渡しするようなRESTful APIを作成していたときに
文字化けが発生しました。

すべてUTF-8で統一されているのになぜ?とあせりました。
Java内部の問題なのかとも思いましたが、開発環境のUbuntuでは
発生してなかったので、ない。

受信周りの問題だなといろいろ調べた結果、
結局はロケールの設定の問題でした。
開発環境のUbuntuでは、

$ locale

の結果が、

$ locale
LANG=ja_JP.utf8
LC_CTYPE="ja_JP.utf8"
LC_NUMERIC="ja_JP.utf8"
LC_TIME="ja_JP.utf8"
LC_COLLATE="ja_JP.utf8"
LC_MONETARY="ja_JP.utf8"
LC_MESSAGES="ja_JP.utf8"
LC_PAPER="ja_JP.utf8"
LC_NAME="ja_JP.utf8"
LC_ADDRESS="ja_JP.utf8"
LC_TELEPHONE="ja_JP.utf8"
LC_MEASUREMENT="ja_JP.utf8"
LC_IDENTIFICATION="ja_JP.utf8"
LC_ALL=

のようになっているのに対してCentOSは、

$ locale
LANG=C
LC_CTYPE="C"


 C…、よくわからない値が入っていました。
なので、localeを編集 して、再起動しました。

$ vi /etc/sysconfig/i18n
LANG="ja_JP.UTF-8"


結果、JSON取得時の文字化けはなくなりました。
Jerseyは賢い子

2011年12月8日木曜日

[ASP]maxrequestlengthのエラー処理

ASPの場合、ファイルのアップロードの制限をしたいという時は、web.configでmaxrequestlengthを設定しますが、そのままだとmaxrequestlengthを超えた場合に”ページを表示できません”画面が表示されてしまいます。そのままだと、どういったエラーが出ているのかユーザに通知できないのでサポートも面倒くさいです。そこで、カスタムエラーを設定すればいいのかと思っていたら、ちょっと違うようです。

詳しくは、
http://www.developer.com/db/article.php/10920_3426051_2
にありますが、どうも日本語では見つからなかったので覚書です。


Sub Application_Error(ByVal sender As Object, _
 ByVal e As EventArgs)
    ' Fires when an error occurs
    ' Check to see whether we came 
    ' from the upload form
    If Path.GetFileName(Request.Path) = _
     "UploadForm.aspx" Then
        ' Get the error details
        Dim appException As System.Exception = _
         Server.GetLastError()
        Dim checkException As HttpException = _
         CType(appException, HttpException)
        ' Verify the expected error
        If checkException.GetHttpCode = 400 And _
         checkException.ErrorCode = -2147467259 Then
            ' Error 400 = bad request, user 
            ' tried to upload a file that's too large
            Session("ImageTooLarge") = True
            Server.ClearError()
            ' Go to the original target page
            Response.Redirect("UploadForm.aspx")
        End If
    End If
    ' For other errors, just accept the default processing
End Sub

MavenのJDKバージョン設定

激しく構成が乱れてるけど、とりあえず公開しておきます。
そのうち直します。


Mavenでコンパイルエラーが発生しました。


注釈は -source 1.3 でサポートされていません
(注釈を使用可能にするには、-source 5 以降を使用してください)
    @Override

MavenのデフォルトでJDK1.3を使用しているために発生しているようです。
JDK1.3だと注釈、型指定のリスト、Foreach等が使えず割と不便。
 JDKを変更するためにはpom.xmlのpluginに次の項を追加します。


 <build>
 <properties>
  <java.version>1.6</java.version>
 </properties>
 
 <plugins>
  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>2.3.2</version>
   <configuration>
    <source>${java.version}</source>
    <target>${java.version}</target>
   </configuration>
  </plugin>
 
参考
https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html

サーバのブルートフォース攻撃対策

気づいたら結構な頻度でブルートフォース攻撃されているようなので
次のようなiptablesの設定を追加しました。

$ sudo /sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
$ sudo /sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j DROP

 22ポートにコネクションが60秒に4回アクセスされると60秒アクセスを停止する。
 次のような結果が出たら成功。 

$ sudo /sbin/iptables --listtarget     prot opt source               destination         
DROP       tcp  --  anywhere             anywhere            tcp dpt:ssh state NEW recent: UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source 
           tcp  --  anywhere             anywhere            tcp dpt:ssh state NEW recent: SET name: DEFAULT side: source 
認証は128bitキーのみにしてるから気休めですが。
このあたりが詳しそう
 iptables の ipt_recent で ssh の brute force attack 対策