- PR -

【ASP.NET】セッション変数の値を外部で利用する方法

投稿者投稿内容
ひろれい
ぬし
会議室デビュー日: 2006/03/02
投稿数: 486
お住まい・勤務地: 万博開催地
投稿日時: 2006-05-12 09:57
引用:

ちょっと視点が変わりますが。

HttpModuleを使ってみるのはどうでしょう。
UpdateやDeleteの際のリクエストのパターンを全部洗い出す必要はあるかもしれませんが、現行のソースに何も手を加えず、ユーザの操作をロギングできるかと思います。
Session変数の状態がきちんと格納されてからとなると、PreRequestHandlerExecuteイベントに対して独自の処理メソッドを実行するような形になるでしょう。
このイベントはページの処理がはじまる直前に発生するので、この時点でブラウザからのリクエストの内容を確認し、UpdateやDeleteのパターンに一致する場合にSession変数内のユーザ情報とリクエストのなかから必要なデータを取り出してログに残すことができるはずです。


どっとねっとふぁんさん、お返事ありがとうございます。

HttpModule を手掛かりに調べてみましたが、敷居が高そうですね(^_^;)

http://www.ascii.jp/pb/msdn/article/a30_0050.html

製造前なら色々と試してみたいと思うのですが、現時点から技術調査していくのは難しいかなぁ、と思ってしまいます。安易な方法に流されてはいけないんですけど・・・

引用:

Accessさんの書き込み (2006-05-12 06:13) より:

欧米の政府関係のシステムでは会計監査上の理由で、テーブルからレコードを物理的に削除することは禁止されているようです。削除フラグを付けて論理削除するのが一般的なようです。

グーグルで検索したら同じような記事がありました。英語ですが、よろしければ参考にしてください。

http://www.developerfusion.co.uk/show/2413/


論理削除が一般的なんですか?! ちょっと衝撃です。
監査すべき期間はデータを消しちゃいけないんでしょうね(不正防止)。
ただ、監査の必要のないシステムにとってはDB回りの設計をかなりシッカリしないと論理削除はシステムに影響が出そうですね。

教えていただいたページを眺めてみました。英語力が乏しいため、意味を全て理解できないのが悲しいです(^_^;)
これは、どういう仕組みなんでしょうか?
WindowsNT チャレンジ/レスポンス認証というものを使って、Request.ServerVariables("LOGON_USER") をアカウントID としているようですが。単純に、これを Session変数で管理しているユーザID に変えれば良い、というレベルではないですよね。

当然、複数のユーザがシステムを利用するわけですが、その辺の切り分けがどのようになされるかが読み取れませんでした。
かるあ
ぬし
会議室デビュー日: 2003/11/16
投稿数: 1190
お住まい・勤務地: センガワ→ムサシノ
投稿日時: 2006-05-12 10:08
v$系のView を使ってどうにかできないかなー
とか考えていましたが、

(出来るかわかりませんが
トリガーが起動されたセッションIDから
前回投げたSQLのパラメータをみて
うにゃうにゃうにゃとか)

解りにくくなりそうですし
やっぱりプログラム側からログを出すのが
素直で安上がりになるんじゃないでしょうか
ぽぴ王子
ぬし
会議室デビュー日: 2006/03/24
投稿数: 475
お住まい・勤務地: お住まい:城・勤務地:城
投稿日時: 2006-05-12 10:10
こんにちは。

ひろれいさんが開発されているのが欧米の政府関係のシステムかどうかはわかりません
が(笑)様々な理由で物理削除を止めて削除フラグで制御しているシステムも結構あり
ますね(私が現在開発しているシステムもそうです)。
そこで少し考えていたのですが、テーブル上に削除フラグを設け、プログラムの削除処理
では DELETE を発行するのではなく UPDATE で削除フラグと更新ユーザIDを更新し
てもらうとして。そして UPDATE トリガで「削除フラグが UPDATE されたら」ログを出力
後にトリガ側で DELETE をかけてみるという感じで(できるのかどうかは不明)。

自分が担当しているとしたらどうするかで考えたら上記のような解決案になりましたが
プログラムとテーブル(あとトリガ)の変更が必要だったりするので、数が多いとちょっと
('A`)マンドクセ って感じになるかもしれませんね。
ひろれい
ぬし
会議室デビュー日: 2006/03/02
投稿数: 486
お住まい・勤務地: 万博開催地
投稿日時: 2006-05-12 10:33
引用:

ぽぴ王子さんの書き込み (2006-05-12 10:10) より:

ひろれいさんが開発されているのが欧米の政府関係のシステムかどうかはわかりません
が(笑)様々な理由で物理削除を止めて削除フラグで制御しているシステムも結構あり
ますね(私が現在開発しているシステムもそうです)。
そこで少し考えていたのですが、テーブル上に削除フラグを設け、プログラムの削除処理
では DELETE を発行するのではなく UPDATE で削除フラグと更新ユーザIDを更新し
てもらうとして。そして UPDATE トリガで「削除フラグが UPDATE されたら」ログを出力
後にトリガ側で DELETE をかけてみるという感じで(できるのかどうかは不明)。


かるあさん、ぽぴ王子さん、お返事ありがとうございます。

ぽぴ王子さんから提案していただいた方法でも可能だと思います。
UPDATE の TRIGGER で、削除フラグが変更された場合だけ起動するようにし、ログを出力した後、物理削除する、という感じですね。
ただ、この方法だと、テーブルに修正が入る分、単純に DELETE 時にログを出力する方法より手間がかかりますね。

やっぱり、素直に UPDATE は TRIGGER で、DELETE はアプリ内からログを出力する方法が1番手っ取り早いみたいですねぇ
ぽぴ王子
ぬし
会議室デビュー日: 2006/03/24
投稿数: 475
お住まい・勤務地: お住まい:城・勤務地:城
投稿日時: 2006-05-12 11:03
私の提案した方法は「あくまで手っ取り早く収める方法」ということで、実際のところは他
の皆さんと同じく「全部プログラムでログ出そうぜ、な!」という感じだったりします。
(以上たぶん自分が後輩に相談されたらそう答えるだろうシミュレーションテストでした)

UPDATE 後に DELETE 方式は苦肉の策というか、DELETE するときに更新ユーザ
IDがわからないんだから UPDATE で(削除フラグを)更新してしまえ→削除フラグが立
っているレコードをいつ削除するのん?節子それ DROP やない! TRIGGER や!(意
味不明)というわけでトリガでログ出力&削除という無理やり感丸出しで考えてみました。
保守性とかまったくもって無視されてますね orz

で、それを踏まえたうえで、DELETE 用のログをアプリから出力させるのであれば、じゃあ
UPDATE だってアプリから出力させればいいじゃん?と思ったわけで。
本音を言えば、プロジェクトが行き詰ってからのこういった変更って結構めんどくさいですよね
(最初から考えておけよ案は甘んじて受けます
ひろれい
ぬし
会議室デビュー日: 2006/03/02
投稿数: 486
お住まい・勤務地: 万博開催地
投稿日時: 2006-05-12 11:35
引用:

ぽぴ王子さんの書き込み (2006-05-12 11:03) より:

私の提案した方法は「あくまで手っ取り早く収める方法」ということで、実際のところは他
の皆さんと同じく「全部プログラムでログ出そうぜ、な!」という感じだったりします。
(以上たぶん自分が後輩に相談されたらそう答えるだろうシミュレーションテストでした)

UPDATE 後に DELETE 方式は苦肉の策というか、DELETE するときに更新ユーザ
IDがわからないんだから UPDATE で(削除フラグを)更新してしまえ→削除フラグが立
っているレコードをいつ削除するのん?節子それ DROP やない! TRIGGER や!(意
味不明)というわけでトリガでログ出力&削除という無理やり感丸出しで考えてみました。
保守性とかまったくもって無視されてますね orz

で、それを踏まえたうえで、DELETE 用のログをアプリから出力させるのであれば、じゃあ
UPDATE だってアプリから出力させればいいじゃん?と思ったわけで。
本音を言えば、プロジェクトが行き詰ってからのこういった変更って結構めんどくさいですよね
(最初から考えておけよ案は甘んじて受けます


今回の PJ は、「基本ノーメンテ」という依頼があったため、ログを設計から省いていました。(この時点で間違いだったことは、おおいに反省しております)

しかし、製造過程でユーザ殿の担当者が変わり、「再度プロト見せて」と言われ、その時に「誰でも入力データをメンテできるんですね」というご指摘があり、利用ユーザに権限を設定する方式も考えたのですが、「厳密に誰がどういう作業をするかは、運用してみないと・・・」って話があり、最終的に「じゃあ、ログを採って、後から追えるようにしておこう」となった、という経緯がありまして・・・

ぽぴ王子さんが言われる通り、「最初からログの方式を盛り込んでおく」のが真っ当な道だと私も思います。(反省)
ぼのぼの
ぬし
会議室デビュー日: 2004/09/16
投稿数: 544
投稿日時: 2006-05-12 12:21
いろんな案が出てるようですので、私からも参考に一案。

「削除はトリガーを使わずストプロで」
主キーとユーザIDを受け取ってログ出力と削除処理を行うストプロを作って使う。
そうすれば、もし将来的に「物理削除を止めて削除フラグで制御して」と言われても
ストプロの修正だけで済みます。

スキルアップ/キャリアアップ(JOB@IT)