大津です。 本来ならクライアント・サーバ両側でバリデーションをかけるのが一番確実ですなんですけど。
拡張子なし変なファイルに関しては、どんな送り方をしていて「コメント」が何を指すのか 状況がわからないのであくまで想像ですけど、マルチパートの Content-Dispositionでちゃ んとファイル名が指定されてないのが原因だと思います。(keepExtensionしてる前提ですが） いろいろ可能性はありますけど、クライアント側の処理なので Node から外れちゃいますが text とかの input type でフィールドとして送ったりしてるからじゃないですかね。 （あくまで想像です。） (2013/11/19 22:42), Leo Azuki wrote: > 大津さん > ご返信及びサンプルコードありがとうございました。 > いろいろと考えたのですが、クライアントサイドでチェックできるものはチェックするようにしまして、サーバーサイドでは実はファイルをアップしないでコメ > ントのみのポストの場合もサーバーのアップロード先フォルダに変なファイル（05e350ec18bdb7b95c83029bd7e0b275みたいな何の拡張子もつかないファイルで > > す。）ができてしまいますので、できたものは削除するという方向でいこうと思います。 正常処理、及び異常系の場合も常にアップロードフォルダを見まして > ファイル名.拡張子以外のファイルは削除するという方向で実装してみようと思います。 > 大津さんにご指摘していただいたチャンクのポストの場合など今まで意識したことがありませんでしたので、勉強になりました。 > > ありがとうございました。 > > > 2013年11月19日火曜日 14時15分26秒 UTC+9 shigeki: > > 大津です。 > > あと書くの忘れちゃいましたが、 Expect 100-Continue の対応は面倒なので省いています。 > curl のクライアントテストでも明示的につけないようにしてます。 > > (2013/11/19 14:13), Shigeki Ohtsu wrote: > > 大津です。 > > > > 最初簡単にチェックできるのかなと考えていたのですが、思いのほか複雑になりました。 > > > > POSTでリクエストボディで送られてくるサイズをサーバでチェックするには次の2通りあります。 > > > > 1) クライアントが Content-Length を送ってからボディを送信する時。 > > これは一番簡単で Content-Length のサイズをチェックしてはじけばいいだけ。 > > > > 2) クライアントが Transfer-Encoding: chunked でボディを送信する時。 > > これが一番やっかいで、クライアントから送信されてくるデータのサイズを > > 送られてくる毎に積算してチェックしないといけません。 > > 通常の express の middleware で route すると、ファイル書き込み処理も同時に > > 処理されるのでどうしても制限値までのファイルがpipeで書き込まれる状況になっ > > てしまいます。なので route を使うのはどうしても難しいかなと思います。 > > 替りに新しく request オブジェクトもどきを作ってやって、アップロードサイズ > > チェック後にミドルに渡すという方法ぐらいしかないかなと。 > > （他にスマートなやり方があれば誰か教えてください。） > > > > ということで、サンプルを以下にあげました。 > > > > https://gist.github.com/shigeki/7540543 > <https://gist.github.com/shigeki/7540543> > > > > 利用環境が書いていないのですが、 connect.multipart が deprecate 予定らしいので > > > > https://github.com/senchalabs/connect/wiki/Connect-3.0 > <https://github.com/senchalabs/connect/wiki/Connect-3.0> > > > > 替りに multiparty を使ってます。 node-v0.10.22 + express@3.4.4 で動作確認してます。 > > (express2.x ぽいですが、そこまで見る時間がないです。） > > > > これ見ると、制限値までのファイル作成を許容するか、クライアントからの > > Transfer-Encoding: chunked での POST を禁止して、Content-Length だけのチェックするよ > > うにするか、どちらかにした方が断然楽ですね。 > > > > > > (2013/11/18 22:43), Leo Azuki wrote: > >> 江口さん ご返信ありがとうございます。 > >> > >> >もしかしたら、間違っているかもしれませんが、サーバ側でバリエートチェックした時点では、ファイルがアップロードされちゃうと思います。 > >> > >> > 実はapp.limit('2mb')の部分のバリデートではファイルのアップロードが防がれていまして、ということはサーバー側でなんとかなるのではないかと > 思ったので > >> すがクライアントチェックでやるのもよさそうですね。 ただクライアントチェックですと既にアップされた同名ファイルのチェックは、一度サーバー > 検索かけ > >> た結果をクライアントに戻してチェックする形になるのでしょうか？ > >> > >> node.jsを用いたファイルアップロード処理は結構多そうなのでぜひお知恵を拝借させてください。 よろしくお願いします。 > >> > >> 2013年11月18日月曜日 21時05分39秒 UTC+9 えぐぴょん: > >> > >> こんばんは > >> 江口です。 > >> > >> もしかしたら、間違っているかもしれませんが、サーバ側でバリエートチェックした時点では、ファイルがアップロードされちゃうと思います。 > >> > >> > HTTPはリクエスト−レスポンス方式なので、リクエストの電文にファイルも載ってきてしまいますから、レスポンスで、これは受け入れられなかっ > たと、ク > >> ライアントに返答できますが、リクエストに載ってっきてしまったファイルはサーバ側で削除するしかないとおもいますが・・・ > >> > >> アップロードする前に、クライアント（Webブラウザ側）でバリエートチェックするのがいいと思いますが・・・ > >> > >> 以上、ご参考までに > >> Kazuyuki Eguchi > >> > >> > >> 2013年11月18日 19:56 Leo Azuki <azuk...@gmail.com <javascript:>>: > >> > node.js, expressを用いたシステムを構築中でして、イメージファイルのアップロード処理にてお聞きします。 > >> > > fs.renameを用いてアップロード処理にて、同名のファイル、jpeg,gif,png以外、２メガ以上のファイルはアップロードできないように実装し > ていま > >> > す。、ポスト後のサーバー側の処理にてバリデートは正常にひっかかるのですが、app.postでリクエストが届いた直後に指定のフォルダにファイ > ルがアップ > >> > ロードされてしまっています。（ファイル名はこんな感じです。e84df8517af642bb96bf0cd80e30b100.jpg）バリ > >> > > バリデートにひっかかったら、ファイルはアップロードされないようにしたいのですが、どなたか知恵を拝借させていただきたく投稿いたしま > す。 > >> > よろしくお願いします。 app.configureの設定は以下のようにしています。 > >> > > >> > app.configure(function() { > >> > app.set('port', process.env.PORT || 3000); > >> > app.use(express.limit('2mb')); > >> > app.use(express.bodyParser({ > >> > //onPart: onPart, > >> > keepExtensions: true, > >> > uploadDir: './uploads/fullsize' > >> > })); > >> > app.use(express.cookieParser()); > >> > app.use(express.session({secret: '○○○'})); > >> > app.use(express.methodOverride()); > >> > app.use(express.static(path.join(application_root, > 'public'))); > >> > app.use(flash()); > >> > app.use(app.router); > >> > app.use(lib.notFoundHandler); > >> > app.use(lib.errorHandler); > >> > }); > >> > > >> > -- > >> > > >> > --- > >> > このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > >> > > このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.com > <javascript:> <javascript:> にメール > を送信します。 > >> > その他のオプションについては、https://groups.google.com/groups/opt_out > <https://groups.google.com/groups/opt_out> > <https://groups.google.com/groups/opt_out > <https://groups.google.com/groups/opt_out>> にアクセスしてください。 > >> > >> -- > >> > >> --- > >> このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > >> このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.com > <javascript:> にメールを送信します。 > >> その他のオプションについては、https://groups.google.com/groups/opt_out > <https://groups.google.com/groups/opt_out> にアクセスしてください。 > > > > -- > > --- > このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.com にメールを送信します。 > その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。 -- --- このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.com にメールを送信します。 その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。
