7月 232014
 
  • 調べた分だけ。
  • 割とわかりやすかった:Overview of Custom Storage Providers for ASP.NET Identity | The ASP.NET Site
  • 「ASP.NET Webアプリケーション」テンプレートの認証「個人ユーザーアカウント」で作成されたコードを眺めれば何となく分かる。
  • Microsoft.AspNet.Identity.EntityFrameworkとかはEFのCodeFirstでテーブル初期化とかDB読み書きとかやってくれるやつだけど、CodeFirstが嫌でIUserStore自作するなら不要な感じ。
  • UserManagerがASP.NET Identityの中心的存在の予感。
    • OWIN startup classの中でCreatePerOwinContext()にて初期化用Funcを設定する。

PasswordHasherの入れ替え

[csharp]

public class ApplicationUserManager : UserManager
{
public ApplicationUserManager(IUserStore store) : base(store) { }

public static ApplicationUserManager Create(IdentityFactoryOptions options, IOwinContext context)
{
var manager = new ApplicationUserManager(new UserStore(context.Get()));
manager.PasswordHasher = new HogePasswordHasher();
return manager;
}
}

public class HogePasswordHasher : IPasswordHasher
{
public string HashPassword(string password)
{
// 塩を振ったりストレッチングしたりしよう
throw new NotImplementedException();
}

public PasswordVerificationResult VerifyHashedPassword(string hashedPassword, string providedPassword)
{
if (hashedPassword == HashPassword(providedPassword))
return PasswordVerificationResult.Success;
else
return PasswordVerificationResult.Failed;
}
}
[/csharp]

ちなみに、ASP.NET vNext のデフォルトっぽいPasswordHasherは以下の様な実装。

  1. Rfc2898DeriveBytesでSaltサイズのみ指定(128bitでRNGCryptoServiceProviderによって生成されるランダムSalt)にしてパスワードハッシュ生成(1000回ストレッチング)
  2. Salt + パスワードハッシュな文字列を返す(DBとかに保存する文字列になる)

検証時は

  1. DB保存的文字列からSaltとパスワードハッシュを切り離し
  2. そのSaltを利用して、入力されたパスワードからパスワードハッシュを計算
  3. 照合

2.0.0のMicrosoft.AspNet.Identity.PasswordHasher.VerifyHashedPassword()も、vNextのコードで生成したハッシュを使って検証したら成功したので、多分同じロジック。

参考:Identity/src/Microsoft.AspNet.Identity/Crypto.cs

Roleによる認可的な

Controllerで

[csharp]
if(this.User.IsInRole(“Admin”))
{
}
[/csharp]
とか
[csharp]
[Authorize(Roles=”Admin”)]
public ActionResult Index()
{
return View();
}
[/csharp]
とか。

Viewで

[csharp]
@if (this.User.IsInRole(“Admin”))
{
}
[/csharp]
とか。

7月 222014
 

そのうちまとめるつもり。

  • .NETのカラマネ対応APIは、System.Windows.Media, System.Windows.Media.Imagingの中にちょっとだけある。ほぼWPF専用なのではないかという予感…
    クラス / 構造体 概要
    ColorConvertedBitmap WICで一度だけ色変換できるBitmapSource。微妙MarkupExtensionもあるよ。
    ColorContext ICCプロファイル的なやつ。
    Color sRGB/scRGBカラーを扱う。挙動が微妙なこともあり、カラマネ的には役に立たない可能性が。
    BitmapFrameと各種Encoder/Decoder 画像ファイルを取り扱うクラス群。画像プロファイルも読み書きしてくれるっぽい。中身はWICの模様。

  • 内部的にはICM / WCS, WICを利用している。
    • System.Windows.MediaがICMに対応して、System.Windows.Media.ImagingがWICに対応するイメージなのかな?
  • いずれの場合もTransformは使い捨ててるので、パフォーマンスは微妙。
    • WCSプロファイルはTransform生成がかなり遅い(iccの30倍位)ため、非常に残念な事になる。回避するには多分P/Invokeしかない。
  • 残念なことにデバイスプロファイル等、PC/ユーザーに設定されているプロファイルを取得する方法は用意されていないので、ファイルパスを指定するかP/Invokeするしかない。

System.Windows.Media.Imaging.ColorConvertedBitmap

  • 変換元、変換先のColorContextと、変換したいBitmapSourceを指定して色変換できる。
  • これ自身がBitmapSourceを継承してるので、Image.Sourceとかに指定できる。
  • 一度初期化したら変更できない。
  • 内部的にはIWICColorTransformを使ってる。
  • ColorConvertedBitmap のマークアップ拡張機能なんてのもあるが、各プロパティ指定できるの一度きりだし、果てしなく微妙。

System.Windows.Media.ColorContext

  • イメージ的にはICCプロファイルとかと同じ。
  • 内部的にはColorContextHelperを通してICMのOpenColorProfile()GetColorProfileHeader()を利用している。
  • PixelFormatを指定して初期化することでsRGBとかscRGBのColorContextを取得できることになっているが、実際に取得されるのは コントロールパネル>色の管理>詳細設定>デバイスプロファイル に設定されているプロファイルだったり。
    • これはICMのGetStandardColorSpaceProfile()を利用しているからで、sRGBのプロファイルIDを指定しているにもかかわらず上記のような結果になるという謎挙動が原因である。
    • 既定のデバイスプロファイルではなく、ちゃんとsRGBを指定したいならば、自分でURIを指定する必要がある。

System.Windows.Media.Color

  • 一見RGBを抽象化したものに見えるが、実際はsRGB/scRGBカラーを取り扱う構造体である。
  • FromValues()およびFromAValues()にてColorContextを指定できるが、これは非常にややこしいことに「指定されたColorContext」→「既定のデバイスプロファイル(大抵はsRGB)」という変換となる。
    • 最初は「指定されたColorContextのRGB」を表す型なのかと思ってたら全然違った。
    • ComputeScRgbValues()というprivate methodの中で、PixelFormats.Bgra32を用いて変換先ColorContextを初期化しており、このソースを見る限りは本当はsRGBを変換先とするつもりっぽいのだけど、上記ColorContextの謎挙動により既定のデバイスプロファイルが変換先となってしまっている。
    • この変換処理ではColorTransformというinternal classを使っている。それ使わせてくれよ…
      • ColorTransformは、ColorTransformHelperを経由してICMのCreateMultiProfileTransform()TranslateColors()をやってくれるクラス。
    • 一色変換するだけの処理にもかかわらずTransformを使い捨てしており、コスト的にも大分残念な感じになっている。何に使うんだろうこれ…

System.Windows.Media.Imaging.BitmapFrame とか

  • まだあまり試してないが、画像プロファイルの読み書きができそうで良さ気。
  • System.Windows.Media.Imagingは大体WICと同じ雰囲気っぽい?
  • 内部的には完全にWIC依存。
  • でもIWICColorTransformとかは使わせてくれない微妙な感じ…
  • BitmapFrame.Create時などにBitmapCreateOptions.IgnoreColorProfileを指定していないと、埋め込まれた画像プロファイルからsRGB (これも同様にデバイスプロファイルかも知れない) へ変換される
    • 変換されるくせに埋め込まれたプロファイルColorContexts[0]はsRGBに置き換えられず、そのままである
    • これに気付かずにColorConvertedBitmapに食わせると、二重に変換されたりして悲しい思いをする
    • BitmapCreateOptions.IgnoreColorProfileを指定した場合、元のカラースペースを保持した状態で読み込まれる
  • CMYK画像をBitmapFrame.Createする際にBitmapCreateOptions.PreservePixelFormatを指定していない場合も、RGB PixelFormatへ自動変換される
    • 同様に、プロファイルが埋め込まれていた場合ColorContexts[0]はCMYKプロファイルのままである
  • BitmapCacheOption.None以外で読み込んだ場合、その時に指定されたBitmapCreateOptionsで画像がキャッシュされ、再読込時のBitmapCreateOptionsは無視される
    • Streamから読み込む場合はキャッシュの影響は受けないようだが、即時読込するためにはBitmapCacheOption.OnLoadが必要な点に注意

モニタプロファイルの取得

  • .NET じゃ無理ぽ
  • EnumDisplayMonitors()GetMonitorInfo()MONITORINFOEX取得
    →取得したデバイス名からCreateDC()でデバイスコンテキスト取得
    GetICMProfile()でプロファイルパス取得
  • 実コードとかはそのうち…
7月 172014
 

懐かしの妹。。
何やら発売日より1日早く届きました。
付属の同人誌的なものが付いているのですが、オリキャラでこういうのは嬉しいですね。
全体的に割と無難によく出来てます。
克氏のものでは初期には奇抜な抱き枕カバーがいくらかありましたが、最近はいい感じのものが多いですね。素晴らしい。

※この先18歳未満は閲覧禁止※

Continue reading »

7月 162014