やぁ、みくみくなスコサバででたバグとか、新しいアイディアとかを
ほぼほぼ出来上がってたモンハンのスコサバに取り込みつつ作業してたんだけど、
微妙にデグレってて焦って
ごちゃごちゃしてたのは秘密です＞＜；
えぇ秘密ですともorz

あと、ユーザー登録の方式をどうしようかずっと考えていたんだけど・・・
やはり現状の方式だとコミュニティサイトとしてはかなり不完全なので
一番手間をかけない方法でいくことにしました。

構成としてはDBを１つ作って、
そこにログインコントロール周りのテーブル、スクリプト、ビュー
＋
スコサバのテーブルとスクリプト
を混在させるサイトを、みくみくなスコサバとは別にもう一つ作るイメージです。

つまり、みくみくなスコサバと、モンハンのスコサバは別登録にすることにしました。
どう不完全なのかは、別途あらためてまとめて見ようかと思いますが、
現状だと、駅の伝言板レベルに近い使い方しかできません・・・ということですね。
ひっそりやってれば問題ないんじゃないかと思いますが＾＾；

あと、同じドメインで２つWebアプリを公開したらSession の扱いはどうなるんだろう？
とかですね、多少テストしないといけない部分もあります・・・

今週末には公開できるといいなぁ・・・
や、１つサイトをUPできたので、一息ついてDQにはまっているわけでは・・・
ありま・・・・・・・・すんすんｗｗ

うーむ、Gogax から連絡がこなーいよorz

質問の１個目にはちゃんと答えが来たから
コミュニケーションに問題はないはずだが・・・

２２日に２つ質問出して、１つは２４日に回答があった。
でももう一つは、２６日に催促メールしたけど、
まだ回答こない。

でも、同じ操作をすると、いままでは必ずエラーメッセージが出てたけど、
今日試したら、エラーメッセージはでない。
ただ、操作が完了してないだけ。

向こうではなにかちゃんと調査なり進展なりが
あることを信じてる～信じてるから～～＞＜；

まぁ正直、はやいとこ解決してくれないと
モンハントライが発売されちゃうじゃないかよーよーよーょーょー

もうね、公開する気まんまんだったてのに
どうしてくれましょう・・・

うーーむ
まぁ時間が解決してくれそうな気もするんですが

次のお題は自宅サバですかね？？？

 無料サバも検討したけどなかなかよさそうなのがないすな・・・

ここは結構よさげかも
ActiveWeb
http://www.activeweb.jp/

まぁGogaxが頑張ってくれることに期待します

ちょっとだけ前進～

（３４）であげていた問題の１つ、
■メニューからASPNETを有効にできない
については、
due to a bug with hsphere

とのことで、どうやらH-Sphere というソフトのバグが原因らしい。
んで、manually に configured the asp.net してくれたと。

ん～でも設定画面上、有効になってるように見えないんだが・・・。

んで、あれこれやるうちに、
ASP.NET のエラーが出るようになった～
うむ、これは前進だ☆やったねｗ

で、エラーってのはハッカーにとっても
有益な情報をいっぱい漏洩してしまうので、
デフォルトでは、ガードされてたいした情報を出力しないようになってる。

＜参考＞
＠ＩＴ
［ASP.NET］独自のエラー・ページを設定するには？
http://www.atmarkit.co.jp/fdotnet/dotnettips/165aspcusterr/aspcusterr.html

上のサイトを参考にして、さしあたっては次のように
web.config を書き換えておいた。

<customErrors defaultRedirect="customError.html" mode="Off" />
<compilation debug="true">

これで、ソースもろともがっつりエラー情報を漏洩してくれますｗ
（customError.html は別に用意してないけど、特に怒られなかった）

まず、最初にでたのはweb.config の次の部分。

<authentication mode="Forms">

え、もしかしてフォーム認証つかえない？？
と思って、
<authentication mode="None">
にしてみても同じエラーがでた・・・。

Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. ?This error can be caused by a virtual directory not being configured as an application in IIS.

＜参考＞
.Net放浪記録
ASP.Netでアプリケーションのルートフォルダ以外でweb.configの値を再設定するとエラーが出る件
http://d.hatena.ne.jp/iltc/20080129/1201588250

参考にさせて頂いたサイトのエラーメッセージが日本語訳バージョンらしい。
どうやら、machine.config で、authentication mode の
上書きが禁止されている模様・・・そして、
machine.config をいじくる権限は多分ない（だろうなぁ）と。

ただ、今回の場合、どうもASP.NET のサイトを
アップロードするディレクトリの階層が間違っていたのが原因かもしれない。
authentication タグを削除、
もしくは正しいと思ったディレクトリ階層への移動でエラーが出なくなった。
（ここはGogax 特有の話？も含まれそうなのでこれ以上のことは省略）

んで、現状はこんなエラー。

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

どうやら、一番最初にＤＢにアクセスしにいったところでエラーになってる。

（３４）であげていた問題のもう一方。
■ＤＢの設定で内部エラー

が関係していたりしてなかったりするかもしれない・・・
 

マスターページに機能を盛っちゃうと、
マスターページにも共通処理が欲しくなってあんまりおいしくない？？

だからマスターページのContentPlaceHolder を複数使用する方式を試してみた。

.master ファイルに、ツールボックスから２個目の
ContentPlaceHolder コントロールを放り込んでみる。

<asp:ContentPlaceHolder ID="ContentPlaceHolder2" runat="server">
</asp:ContentPlaceHolder>

うん、勝手に ContentPlaceHolder2 というＩＤが振られる。
で、「新しい項目の追加」「Web フォーム」で、
この状態のマスターページを選択してみた。

<%@ Page Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true" CodeFile="UserLogin.aspx.cs" Inherits="UserLogin" Title="無題のページ" %>

<asp:Content ID="Content1" ContentPlaceHolderID="head" Runat="Server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder2" Runat="Server">
</asp:Content>
<asp:Content ID="Content3" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">
</asp:Content>

むむ、ContentPlaceHolder1 と ContentPlaceHolder2 が用意されてる。
なるほど、１つのページに両方を記述できるのか・・・？

でも今回試したいのは、ContentPlaceHolder2 だけを使って
ユーザーコントロールのごとくコンテンツページを使う方式だ。
どのページにもContentPlaceHolder1 、ContentPlaceHolder2 の
両方を記述しないと使えないって話だと方式的には問題アリで使えないなぁ。

とりあえず、ID="Content3" の部分は削除した。
あと、ID="Content1" は各ContentPlaceHolder のヘッダーとして
使えるんだろうけど、使ってないです。（まぁ削除はしなかった）

さて、２個目のコンテンツプレースホルダーに表示される
コンテンツページを次の様に記述してみた・・・。

<asp:Content ID="Content2" ～>
    <asp:LoginView ID="LoginView1" ～>
        <LoggedInTemplate>
            ログイン済みの時に表示させたい内容
        </LoggedInTemplate>
        <AnonymousTemplate>
            未ログイン時に表示させたい内容
        </AnonymousTemplate>
    </asp:LoginView>
</asp:Content>

ま、見た感じは余裕で動きそうだったんだけど・・・
ログインした後、LoggedInTemplate の内容が表示されない＞＜；

な、なんで？？？
あぁ・・・なんでもなにも

<asp:Content ID="Content2" ～>
</asp:Content>

内を記述してあるページ以外ではその部分は表示されないのか・・・。
しかしそうなるとこの方法は問題アリだｗ
同じ記述を全部のページにして回るのはよろしくないorz

うーん、マスターページに処理を持ってもらう方が良いのか・・・。

しかしそうすると、マスターページとコンテンツページでの共通処理は
どうやって持つのが良かろうという話が再び浮上してくるな・・・。

ふむ、今回は妥協して、
コンテンツページ用にはdll にて共通処理（前回の継承方式）を用意して、
マスターページは（１つしかないので）、
同等の処理を直接.master.cs ファイルに記述することにしますかね～
 

あい、レンサバ応答ありました・・・
・・・バグだったので手動でなんとかしました的なｗ
やっぱネイティブの方の英語はexite翻訳だと微妙よの～＾＾；
動けるかもしれないです。でも今回は別の話。

今回は各ページ間に共通する処理をどうしたらよいだろう？という話。
（例えばログ出力とか、全ページに関係するような前処理とか）

や、いまさらではあるんだけど、しっくり来てないのでね～
なにかないかなぁと探すうち、よさげな情報を見つけた。

＜参考＞
＠ＩＴ
.NET TIPS
［ASP.NET］アプリケーション共通の処理をPage派生クラスで実装するには？
http://www.atmarkit.co.jp/fdotnet/dotnettips/295pagevalidate2/pagevalidate2.html

継承イメージの図があるのでリンク先ページを見てください。

そう、Page オブジェクトにアクセスしたいのだ。
System.Web.UI.Page の継承クラスを用意する・・・。
これはピンと来た。
なんでいままで気づかなかったかというくらいに＾＾；

どのPage でも使う可能性のあるメソッドは継承クラスに作ってあげればイイ。
可能性があるなんて言わずに、共通の処理は全部詰め込む勢いでいいじゃないか。

いままで手を抜いていた（おぃ
ログやらエラー処理まわりが充実することウケアイだょｗ
（ま、実際には良くある話かもです。
  優良な共通基盤が無い場合、ページ(関数)個別に共通処理に相当する
  処理を組み込んだりして、工数はそのページ(関数)の個数分だけふくれあがる・・・
  テスト、仕様変更、その他もろもろに重い枷が付き、
  そのうち、実質無理だからやらない。
  それが普通になってしまい、運が悪いところで発火するとか・・・）

まず、ページクラスを継承した自作クラスを作成・・・。
あいかわらず、VWD2008 だとDLL の作り方がわからないので、
Visual C# 2008 でビルドします。

dll は、
（１９）『ＡＳＰ．ＮＥＴ』＆『Ｃ＃』
でも使ったけど、説明が下手でいまいちだったので、手順をもう一度。

①ひな形として、VWD2008 で
「新しい項目の追加」→「クラス」を作る。
（これがコンパイルできて、dll が作れればVC#2008 の出番はないんだけど・・・）

②VC#2008 で「新しいプロジェクト」「クラス ライブラリ」を選択。
③VC#2008 で出来た.cs ファイルに①の内容をコピー
  ひな形が欲しかっただけなので、①のクラスはもう要らないです。
  消しておかないと、最後のビルドで同じものがあるって怒られます＞＜。
④VC#2008 で参照の追加
  そのままビルドをしてみるとアセンブリ参照が足りないとおこられるので、
  「プロジェクト」「参照の追加」で「System.Web」を追加する。
  他にも、「System.configuration」とかが必要かも。

⑥出来上がるdll ファイルの名前を変えたい場合、
  VC#2008 で「プロジェクト」「プロジェクト名のプロパティ」を設定
  名前空間・・・ここでは説明しないけど設定しといた方が良いです。
  アセンブリ名は、できあがるdll ファイルの名前になる。
  対象のフレームワークはVWD2008 にあわせる。
  出力の種類はクラス ライブラリになってるはず。

⑦コードを記述

// ページクラスを継承した自作クラス
public class MyPage : System.Web.UI.Page
{
    // 各ページ共通のStatic変数なんかがあっても良いかな
    // 各ページ共通の初期処理関数とか
    // ログ出力関数とか
}

⑧VC#2008 でプロジェクトを保存、ビルドしたら、
  プロジェクトのbin → Release ディレクトリに.dll ファイルができる。

⑨VWD2008 で最上位階層にて「Web サイト」「新しいフォルダ」で
  bin フォルダを作る。

⑩bin フォルダで「既存項目の追加」→できあがったdll を選択する。

⑪VWD2008 で既存のページ(.aspx.cs)に対し、次のように修正を加える
（今までSystem.Web.UI.Page を継承していたのを、MyPage を継承するように修正）

public partial class QuestScore : System.Web.UI.Page
{

↓

public partial class QuestScore : MyPage
{

注意：マスターページや、ユーザーコントロールはもともと
      System.Web.UI.Page を継承してないので、MyPage を継承させてはダメです。
      複数マスターページの共通処理を作りたいなら、
       System.Web.UI.MasterPage
      複数ユーザーコントロールの共通処理を作りたいなら、
       System.Web.UI.UserControl
      を継承した自作クラスを作ればよいでしょう。

はい、以上で各ページの共通処理が実装できましたょ。
（もちろん、いままで複数箇所に埋め込んでいた共通関数は削除しました）
ただ、マスターページでも同じ処理が欲しかったりするのが微妙・・・。

うん、ここで気が付いた。

『マスターページにも、ユーザーコントロールにも、
  コンテンツページにも、同じような共通処理が欲しいんだけど？？』
なんてなるのは、設計があまりよろしくないと思う。

それぞれになんとなく機能を盛っていくからそんなことになる。
マスターページは、入れ物としての役割に徹する。
ユーザーコントロールとコンテンツページは、
明確にその機能差（それは共通処理の違いに現れる）を定義できない限り、
どちらか一方しか使わない。

そういう設計指針のもとで、『使い分け』をしていれば困ることはない。

うん、他に知識を仕入れたらまた言ってること変わるかもだけど、
これは十分シンプルで理にかなった線引きだと思うな～

現状そうなってるかって？
なってないねｗ
幸い、ユーザーコントロールには共通処理はいらなそうだが、
特に中途半端にマスターページにログイン機能盛ってあるのが美しくない＾＾；
作ってる時、ちょっと違和感はあった・・・。
でも作れちゃうんだよね・・・。
共通処理をどうするか？っていうビジョンがあればこうはならなかった。
ということで反省点追加。

ただ、マスターページを「器」としてだけ使うには、
マスターページのContentPlaceHolder を複数用意する方式を
実際試してないのが微妙だ・・・。

つことで、そこも実践あるのみかな。
仕様変更連発する時はちょっとずつバックアップとりながら慎重に＾＾
でもそこは次回～
 

えーっと。
せっかくつくったスコアサーバなので、どこかに公開しようと思って、
IIS使えるサーバってことで、

ゴーギャックス（Ｇｏｇａｘ）
http://www.gogax.com/

の「Windows Premium」を契約してみたわけです。

現状問題点２つ。

■メニューからASPNETを有効にできない。
「１．１」か「２．０」を選択できるが、どっちを選んでも次のエラー。

Error. Application Pool can't contain ASP NET resources with different versions.

自分のドメインで１つも有効にできてないのに、
異なるバージョンはダメとか・・・。

■ＤＢの設定で内部エラー
先にＤＢの設定でも必要なのかな？と思って操作してみたら・・・。
ユーザー設定で

Error: Internal Error, Tech Support Was Notified

うぉーいｗ

なんとかサポートセンターの仕掛けを利用して、
英語で質問をだしてみた。
質問はInformationTicket というID で管理されるようだ。
まぁそういう窓口がちゃんとあるのは良いことだよね＾＾；

ていうか日本語の情報ぜんぜんなかったよGogax・・・。
紹介してた日本語のサイト以外での記事はほぼ０。

なんという人柱状態ｗ

問題解決するいいんだけど・・・。

最悪、長期戦になりそうなので次の展開を考えないとなぁ・・・。

と、次の展開にそなえて、今回のまとめをしておきます。
（まだ公開もできてないんだが、ほぼ完成とみなしてｗ）

今回作成したスコアサーバーの規模概略

マスターページｘ１
Web フォームｘ９
Web ユーザーコントロールｘ２
Web コンフィグｘ２

テーブルｘ８（認証周りで勝手に作られたテーブルは除く）
ストアドプロシージャｘ１０

作成期間は４週間近くになるのか・・・。
しかもサーバ設定は別だ。

まぁ作りたいものが自分の頭の中にあったので、
これが顧客と何を作るかすりあわせる作業込みだと
軽く見積もって５割増しは見込んだ方がよいかもしれない・・・。
まぁ記事を書きながら、方式を検討しながらって部分もあったから、
もちろんそこは効率化をはかれるだろう。

反省点として、
①各ページにまたがっての共通処理を、統合できてない。
  （ログ出力、スタティックな情報の読込部分）
  このためＣ＃（動作コード）の記述量が２割近く増加してる。
  方式としてＤＬＬの活用を考えるとよさそうだ・・・。
  良さそうなのだが、方式増やしたくなくて妥協してしまった。
  新しく覚えたことばっかりなのでイッパイイッパイだったりしたのれすｗ

②管理テーブルの内容を予定より活かせない設計に妥協してしまった。
  実はあんまり管理テーブル活きてないです＞＜；
  管理者テーブルも使わないことにしました。
  （ここはロールを上手く使うと拡張できそうな気もしています）
  アプリケーショングローバルな情報をGridView などデータコントロールの
  パラメータソースに使う場合、どこに格納するのが良いんだろう・・・。
  わざわざパラメータに持たず、毎回ストアドで管理テーブル読むのも
  １つの手ではあるのだが・・・。
  あとはweb.config 活用したりとか？
  Profile てのはどう使うのかなぁ・・・？？
  とか、ここも方式を練る余地がまだまだありそうな部分です。

③画面の構成方法に若干無駄あり。
 例えば、「全クエスト上位者画面」では、
 ブラウザ上はクエスト数分（２３個）のGridView が表示されます。
 
 これのデザインには次のように方法があって、今回はｂを採用してる。
 ａ．２３個のGridView をデザインする
 ｂ．クエスト種別ごとに３個のGridView をデザインする（★採用）
 ｃ．１個のGridView で済ませる
 
 ｃ案は、クエスト種別を取得するDataList 内に、
 クエストを取得するDataList を持ち、
 さらにその内部にスコア内容を持つGridView を配置する方法だ。
 複雑度からすれば当然 ａ＜ｂ＜ｃ となる。
 
 だが、仕様変更やバグ修正などの手間が次の比率で違ってくる。
 ａ（２３）：ｂ（３）：ｃ（１）
 
 要するにデザインコードの記述量が違う。
 例えば安直にａ案を採用して、
 ２３倍近い工数を請求するのはさすがにアコギな商売だと思うｗ
 だいたいそんな工数は通らずに自分の首が絞まったりするｗｗ
 
 ｃ案でなくｂ案で妥協した理由は、ＤＢ設計時点から
 ｃ案をとった場合に必要となる情報を意識できていなかったから。
 （その結果、ｃ案をとる手間が結構かかりそうだった）
 と、まぁａ案よりダイブましだろうと思ったので。
 
 「クエスト種別を並べる順番」や、
 「クエスト種別のテーマカラー」など、
 デザインを意識した項目をあらかじめＤＢに持ってさえいれば
 すんなりｃ案を採用できたと思う。
 
 ただ、やっぱり手直しは３倍かかりました・・・。
 テストの手間も３倍です。
 ａ案よりマシとはいえ・・・。

④スクリプトを使ってない。
  や、HTML の記述経験が少ないだけかもだけど、
  .aspx ファイルにさらに処理を記述すると読みづらさ倍増のように思う。
  まぁロジックとデザインを分離する観点からはそれで良かったという
  話もあるんだけど、スクリプト使えばサクっと行きそうな部分も
  なんでもかんでもＣ＃(.aspx.cs)で行ってしまった気がしなくもない・・・です。
  サーバ側にもっていく前に処理すべきことが処理できると、
  よりスマートなユーザビリティの高いサイトになった可能性が
  あるんじゃないかなぁ・・・と想像します。
  使ってないというより、ほぼ使えないが正解ですね、えぇすみませんｗ

⑤デザインまわり、ＣＳＳも分かってない
  はい、これも勉強した方がよさそうですね～

こんなところでしょうか。
まぁあとは公開してみてのツッコミ待ちってことで～
いつ公開できるのやら＾＾；

意外なことに、SQLインジェクションに対する脆弱性もありましたorz
おまけ感覚で作った『キャラクタ名変更画面』に・・・。
この画面自体、１００行にも満たないし、機能としては
１レコード１項目をUPDATE するだけなんですが、
やはり何も考えずに作ってしまうと、簡単に穴ができてしまうようです。

「変更」ボタンを押すと、次のようなif文でキャラクタ名の重複チェックをします。

if (ExistSameName(TB_CharName.Text)) // 同名キャラの存在チェック
    L_ErrorMessage.Text = "既に同名のキャラクタが存在します";

TB_CharName は、新しいキャラクタ名を入力するテキストボックスです。
ExistSameName 関数は次のようになっています。

protected bool ExistSameName(string name)
{
    int cnt = -1;

    using (SqlConnection con = new SqlConnection(cs))
    using (SqlCommand cmd = new SqlCommand())
    {
        // ------------------------
        // キャラクタ名重複チェック
        // ------------------------
        cmd.CommandType = CommandType.Text;
        cmd.CommandText = @"SELECT count(*)
                        FROM user_tbl
                        WHERE char_name = '" + name + "'" +
                        "AND delete_flg = 'False'";

        cmd.Connection = con;         
        con.Open();
        cnt = (int)cmd.ExecuteScalar();
        　 con.Close();
    }

    if (cnt >= 1) return true; // 重複あり
    return false;              // 重複なし
}

受け取った文字列 name をそのまま、
where 句に使ってしまっています。
これはまずいデスね。

や、なんかまずいかな？
と薄々は思ってたんですが、ちょっと急いだのと、
当時は確信までは持てなかったので・・・。

ユーザーの入力を、そのままSQL 文に埋め込むのはマズイのです。

＜参考＞
Wikipedia
http://ja.wikipedia.org/wiki/SQL%E3%82%A4%E3%83%B3%E3%82%B8%E3%82%A7%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3

例えば入力が数値や日付などに限定され、正しい入力以外を
RegularExpressionValidator などの検証コントロールで
事前にはじくことができるならば、
（SQL の文法に干渉する入力ができないので）
上の様な方法でも特に問題はないはずです。たぶん。

ですが今回、キャラクタ名の入力には特に制限を設けていないため、
SQL 文の文法をねじ曲げて、好きなSQL 文を実行されてしまうような
（キャラクタ名への）入力が可能になってしまいます。

じゃぁどうすれば良いかというと、
ストアドプロシージャを使って、パラメータオブジェクト経由で
値を渡せば、上手いことリテラルとして処理されるみたいです。

protected bool ExistSameName(string name)
{
    int cnt = -1;

    using (SqlConnection con = new SqlConnection(cs))
    using (SqlCommand cmd = new SqlCommand())
    {
        // ------------------------
        // キャラクタ名重複チェック
        // ------------------------
        cmd.CommandType = CommandType.StoredProcedure;
        cmd.CommandText = "PROC_MHPSP2G_check_user_name";

        SqlParameter prm_char_name =
                new SqlParameter("@char_name", SqlDbType.NVarChar, 25);
        prm_char_name.Direction = ParameterDirection.Input;  // キャラクタ名
        prm_char_name.Value = name;
        cmd.Parameters.Add(prm_char_name);

        cmd.Connection = con;         
        con.Open();
        cnt = (int)cmd.ExecuteScalar();
        con.Close();
    }

    if (cnt >= 1) return true; // 重複あり
    return false;              // 重複なし
}

こうして、（めんどくさがらずにｗ）ストアドを作ります。

CREATE PROCEDURE dbo.PROC_MHPSP2G_check_user_name
(
 @char_name nvarchar(25)
)
AS

SELECT  count(*)
FROM    user_tbl
WHERE   char_name = @char_name AND
    delete_flg = 'False';

RETURN

本当にこれでOKなんでしょうか？
やってることは、まったくもって同じにしか見えません。
つーか同じですねｗ

検証してみたのが以下の図になります。

 

なんだ、「たいしたメリット、デメリットじゃないじゃん」
とは思わないでください。
もっと恐ろしいことも可能になってしまうので、この対策は絶対必要でしょう。

 さてさて、セキュリティ周りも目の届く範囲はどうにかしたし、
あとは本気でサーバーにUPしたいところです～