2018年07月13日

HTTP でアクセスがきても HTTPS に置き換える URL Rewrite 機能


IIS では、HTTP にアクセスがきても、HTTPS に変換する REWRITE 機能が使えますが、標準には含まれていないので、別途インストールする必要があります。

IIS 10 用のは、URL Rewrite からダウンロードできます。

web.config に system.webServer タグの下に、Rewrite タグを追加すれば、書き換えはできますが、上記 URL Rewrite の入っていないIISでホストしようとすると、原因不明のエラーが発生するので要注意。

そもそも、httpと、https が共存するようなシステムを作ることがセキュリティ上どうかと思うわけで、本来は、https だけバインドするような仕組みにして、URL Rewrite モジュールを追加しないのが正解かもしれません。
posted by 開発G at 18:55| Comment(0) | TrackBack(0) | ASP.NET

2016年09月26日

AndroidStudio で簡単に KeyStore ファイルを作成する方法

コマンドプロンプトから入力する方法は面倒だと感じていた人には朗報です。

Build メニューから、Generate Signed APK を呼び出し、Create New ボタンを押すだけで、
KeyStore ファイルを作成するダイアログが表示されます。

posted by 開発G at 16:37| Comment(0) | TrackBack(0) | Programming

2016年08月18日

Google API キーにフィンガープリントで動作環境制限をかける

Google API キーを取得した後、誤って他のアプリ等で同じ API キーをアクセスしてしまわないように、APK ファイルの署名で使った証明書の SHA-1 フィンガプリントを、API キーに関連付けることにより、使用制限をかけることができます。この作業は、API Console で行います。API キーはフィンガプリントを付けなくてもアクセスできますが、アクセス総数をカウントしたり、時間内の呼び出し数の制限があるようなAPIもあるため、他のアプリで誤って使わないように必ずフィンガプリントを付けた方がよいでしょう。

リリース用と、デバック用の APK ファイルは、異なる証明書で署名されているので、異なる SHA-1 フィンガプリントを使っていることになります。このため、リリースの際には、リリース用証明書に含まれている SHA-1 フィンガプリントを使う必要があります。デバック用のフィンガプリントが簡単に見つかるので、このあたりはわかりにくいのですが、次のコマンドにより、リリース用の SHA-1 フィンガプリントを確認できます。

>keytool -list -keystore (program名).jks

API Console では、1つの API キーに対して複数のフィンガプリントを関連づけることもできるので、異なるアプリや、デバックとリリースで共通のAPIキーを使うようにも指定できました。(2016年8月時点)


posted by 開発G at 21:35| Comment(0) | TrackBack(0) | モバイルアプリ開発

2016年05月11日

ハイパーバイザが動かないので仮想マシンが起動できなくなった場合

Hyper-V マネージャは動いているが、仮想マシンを選択して起動しようとすると、
「ハイパーバイザが実行されていないので、仮想マシンが起動できない」というメッセージが表示されました。

Hyper-V マネージャを止めたり、起動したりしていたことが関係していると思いますが、なぜか、

hypervisorlaunchtype = no

の状態になっていました。

管理者権限で、dos プロンプトより、
bcdedit.exe /set hypervisorlaunchtype auto

と実行して、パソコンを再起動したら、ハイパーバイザが実行されるようになりました。

hypervisorlaunchtype = auto としておかないとダメなようです。
posted by 開発G at 20:52| Comment(0) | TrackBack(0) | Programming

2016年02月21日

DefaultAppPool で ファイルアクセスできないときのチェックポイント


WebApp でローカルファイルをアクセスしようとしたときに、「アクセスが拒否されました」等の理由でファイルがオープンできない場合があります。当然、フォルダ等のアクセス権の問題なので、ここから悪銭苦闘が始まります。ワーカプロセスの権限を変えるとアクセスできたりするのですが、Administrator に近い権限を与えるのは危険です。そこで、次の項目をチェックするといいでしょう。

  • ワーカプロセスを起動するIDには、ApplicationPoolIdentity, NetworkService, LocalService, LocalSystem とありますが、なるべく ApplicationPoolIdentity や、NetworkService あたりで動かすとよいと思います。

  • ローカルフォルダにアクセス件を与えます。ファイルのセキュリティタブで、IIS AppPool\DefaultAppPool 等で、読み取り専用の権限を与えます。特定の AppPool を作成した場合には、IIS AppPool\(特定のプール名)を使うと、そのサイトにだけ権限を与えることができます。

  • WebApp のプログラム側では、ファイルは ReadOnly でオープンします。何も指定しないと、ReadWrite オープンを指定されたと思って、アクセス拒否されることがあります。(よくあるミスです。)

  • WebApp でローカルファイルへの書き込みはあきらめましょう。実験したところ、LocalSystem 権限など Administrator 相当でしか、ファイル書き込みはできませんでした。書き込みが必要な場合には、DBの利用を考えた方がいいでしょう。


なぜか、アクセスが拒否される場合は、上記の中でも、ファイルをオープンする際に、ReadOnly にし忘れているか確認してみるといいと思います。


posted by 開発G at 18:49| Comment(0) | TrackBack(0) | ASP.NET