Azure AD B2C のサインイン用メールアドレスを変更する - しばやん雑記
Azure AD B2C を使ってローカルアカウントのサインアップを実装するのが非常に簡単なのですが、用意されているユーザーフローでは登録時に使用したメールアドレスを変更出来ないという問題が出てきます。 プロフィールの編集やパスワードのリセット機能はありますが、メールアドレスを変更することは出来ないためアプリケーション側でどのように対応するかが課題となってきます。とはいえ、完全にメールアドレスを変更できないというわけではないので、メールアドレスを変更する 2 種類の方法を紹介します。 メールアドレスの変更ポリシーを追加 1 つ目の方法は公式サンプルでも提供されているカスタムポリシーを利用した方法です。一般的なメールアドレス変更フローと同じように、まずはメールアドレスが正しいか確認コードを送信後に実際に変更を行うので入力間違いの可能性が低くなります 具体的なメールアドレスの変更フローは以下の
WPF で Data Binding と Command を使ったアプリケーションをシンプルに書きたかった話 - しばやん雑記
数年前から WinQuickLook という Windows アプリケーションを趣味で開発しているのですが、内部実装をガラッと変えた新バージョンの開発進捗が著しく悪いことに悩んでいました。現在 V4 というソリューションで絶賛開発中となっていますが、リリース日は未定という状態です。 このアプリケーションの開発を加速させるために、ViewModel を用意するより簡単な方法を求めていました。 初期バージョンは Windows Shell 周りの実装に力を入れていたので、UI 周りは Window が 1 つでボタンが数個ある程度だったため、大体はコードビハインドを使って書いていたのですが、V4 を機に MVVM で作ろうとしたところ余りにも面倒すぎて止まっているのが現状です。 Window が 1 つのアプリで ViewModel を分離して、更に MVVM フレームワークの導入とかそっちの
Project Volterra 改め Windows 開発キット 2023 を購入した - しばやん雑記
Build 2022 で発表されてから音沙汰がなかった Windows on ARM 開発 PC である Project Volterra ですが、突然 Windows 開発キット 2023 として発表されて、なんと日本でも発売が開始されたので購入しました。 こういった開発者向けデバイスが最初から日本でも発売されるのは珍しい予感です。 日本の Microsoft Store では価格を巡って混乱がありましたが、どうせキャンセルされると分かり切っていたので、正規の料金になったタイミングで購入したところあっという間に届きました。 あくまでも開発者向けという扱いにいるので外箱は段ボールそのままでしたが、本体は Surface と同様に質感が高く、コンシューマ向けにもそのまま発売して問題ないレベルだと感じています。 スペックについては以下の公式ドキュメントに一通りまとまっていました。最新の Win
Windows App SDK 1.1 がリリースされたので UWP アプリを移行してビルド自動化まで対応した - しばやん雑記
Build 2022 合わせで Windows App SDK 1.1 の正式版がリリースされていたようです。あまりリリース自体が話題になっていない気がしますが、UWP アプリケーションからの移行先なので 1.1 対応を行いました。 リリースノートを見る限り、割と地味なアップデートという感があります。ぶっちゃけ 1.1 の機能の大半は 1.0 の時にやっておいて欲しかったものです。 It's here! We've just released WinUI 3 in #WinAppSDK 1.1 Stable with several new features & stability improvements to check out✨ 🔎 Release notes: https://t.co/cAK8nb7MHo 🛠 Get started: https://t.co/aya1pKT
Windows Property System を使って C# から曲情報を取得する - しばやん雑記
GW なので趣味アプリの開発を行っていると、音楽ファイルに保存された曲情報を取得する必要が出てきたので、Windows Property System を使って実現したという話です。 曲情報というのは以下のようにファイルのプロパティから確認出来るメタデータのことです。 単純にファイルからメタデータを読み込むだけなら TagLib# というライブラリを使うと、特に難しい処理が必要なく読み取ることが出来ます。しかし最近はアップデートがほぼ止まっていて、偶に PR はマージされていますがリリースがされていない状態が続いています。 そういう経緯もあり、別の方法を検討した結果 Windows Property System に辿り着きました。 Windows Explorer やファイルのプロパティから確認出来る各種メタデータは、Windows Property System という統一されたインタ
App Service Authentication と Azure AD B2C の組み合わせでログアウトを正しく実装する - しばやん雑記
少し前に App Service Authentication が OpenID Connect に対応したので、様々な IdP を利用することが出来るようになりました。Azure AD B2C も OIDC 対応によって正式利用が可能になった IdP の一つです。 ログアウト後のリダイレクト先を指定する App Service Authentication から使う時にはログインは当然ながら確認すると思いますが、案外確認が漏れがちなのがログアウトです。ここで単純に /.auth/logout にリダイレクトするだけでは、以下のような懐かしさすらある画面が表示されてしまいます。 普通の Web アプリケーションであれば、ログアウトした後は独自のログアウトしたことを知らせる画面や、ログイン画面にリダイレクトするのが一般的なので遷移先を post_logout_redirect_uri クエリ
Azure AD と App Service Authentication を使って Web App と Web API を保護する - しばやん雑記
Azure AD 認証と App Service Authentication を組み合わせて、Web App へのログインを行いつつ同時に発行されるアクセストークンを利用して、別に用意された API を実行したいというシナリオが存在します。 Microsoft Graph API を呼び出す場合はアプリケーションに許可するスコープを追加すればよいですが、自前で用意した API の場合にはまず API を公開するという設定が必要になります。 公式ドキュメントでも Web App から Web API を呼び出すシナリオが紹介されていますが、Azure AD にアプリケーションを登録するあたりは若干省略されていてわかりにくいです。 最近は Azure AD の設定を Azure Portal からではなく Terraform で全て行うブームが個人的に来ているので、今回も Terraform
Azure Static Web Apps と Front Door の組み合わせが正式にサポートされたので試した - しばやん雑記
少し前に App Service Authentication と Front Door や Application Gateway を組み合わせた時の問題と解決法を書きましたが、ほぼ同じアーキテクチャの Static Web Apps では当時は回避方法が無く利用困難でした。 Static Web Apps はグローバルに分散されて配信されますが、CDN ではないので Front Door を入れてさらに高度なルーティングとキャッシュを行いたくなることは多いです。 当然ながら非常に困る挙動なので GitHub に Issue を作成していたのですが、先日対応完了したというコメントを貰ったので再度検証することにしました。 まずは適当に Static Web App を Standard で作成して、カスタム認証として Azure AD B2C を設定したアプリケーションを GitHub 経
.NET Framework 3.0 で作られたアプリケーションを .NET 5 に最新化して GitHub で公開するまでに行ったこと - しばやん雑記
CodePlex に置いてあった .NET Framework 3.0 時代に書かれたアプリケーションを、GitHub に移行しつつ .NET 5 で動くように 2 週間ぐらい頑張った話を書きます。正直なところ 12 年前に書かれたコードを何とかするのはめっちゃ大変でした。 今回コードの改善を頑張ったので色々な実験場としても使えるようにしています。特に GitHub 周りは新しい機能を使ってみるようにしています。 .NET Framework 3.0 時代に書かれたコードを何とかするのが本当に大変だった（まだ何とか出来てない https://t.co/u5SrISQRCL— Tatsuro Shibamura (@shibayan) 2021年5月9日 実際には .NET 5 で動くようにはなっていますが、中身は古臭い実装がたくさん残っているので、ツイートの通り全然何とかなっていない状況で
私が Azure Functions アプリケーションの開発時に意識していること - しばやん雑記
ここ数年は Azure Functions をフルに活用したアプリケーションを実装することが多かったのですが、同時に Azure Functions を失敗しないように使う方法も分かってくるので、ここらでちゃんと言語化しておきます。 最近は特に Azure Light-up というハッカソンを行うことが多いのですが、Azure Functions を使う場合には必ずこの辺りは毎回説明するようにしています。要するに Azure Functions の利点・特性を理解して賢く使いこなそうという話です。 Binding / Trigger で実現出来ないか考える Function の実装は出来る限り小さく保つ リトライのしやすい実装を重視する 最新の .NET での作法に沿ったコードを書く Graceful Shutdown に対応したコードを書く 機能単位で Function App プロジェ
Azure Functions の .NET 5 対応と関係する注意点 - しばやん雑記
.NET 5 がリリースされて少し経ちますが、App Service は Early Access という形ですが .NET 5 への対応が行われたのに対して、Azure Functions は今のところ .NET Core 3.1 までの対応となっています。 少し前から Azure Functions の .NET 5 対応に関して GitHub では悪い意味で盛り上がっているのと、パッケージの更新を行うと動かなくなってしまうケースがあるため、注意喚起のために書きます。起こっていることは以下の Issue から辿れば分かります。 先に軽く概要を書いておくと、Azure Functions は v1 から v3 までのランタイムが存在していて、それぞれが .NET Framework / .NET Core 2.1 / .NET Core 3.1 をターゲットにしています。基本的には LT
Cosmos DB のインデックスポリシーの基本と最適化の方法 - しばやん雑記
Cosmos DB は RDB のようにインデックスを個別で付ける必要がなく、デフォルトのままでも十分なパフォーマンスが出るようになっていますが、最適化を行うとスループットの向上やコスト削減に繋がります。 特に最近は大量データの処理基盤として Cosmos DB を使うことが多くなってきたのですが、こういった大量データを処理するケースではインデックスポリシーの最適化はかなり効果が出ます。 例によって Cosmos DB の公式ドキュメントは充実しているので、基本から読んでおくと安心です。 ちなみにインデックスポリシーの最適化のを行う目的は、書き込みのコストとレイテンシを下げるためです。 読み込みに関しては不足しているインデックスを追加した場合には効果が出ますが、必要となる場面は限定的でしょう。最近だと複雑なクエリが必要なら Change Feed か Synapse Analytics を
App Service Static Web Apps の仕組みを探る（非公式） - しばやん雑記
Build 2020 では App Service に関する話は非常に少なかったですが、唯一大きなリリースとしては Static Web Apps がありました。名前の通り静的コンテンツをホスティングするためのサービスですが、同じドメインで API (Azure Functions) が付いてくるのが特徴です。 詳しくは Daria の公式ブログや三宅さんの記事を読んでおいてください。このエントリではその辺りの紹介は全くしないので、知識がある前提で進めていきます。 自分は Static Web Apps がどのように構築されているのかのが気になるので、現在分かっていて触れる範囲で内部アーキテクチャを探ってみました。当然ながら非公式ですし、正しい保証はありません。 Static Web Apps でお手軽ホスティングしたい人には必要ないエントリです。普通は気にせずに GitHub からサクサ
Electron で Surface Pro X にネイティブ対応したアプリを作る - しばやん雑記
Surface Pro X というか ARM64 にネイティブ対応したアプリケーションが中々増えないですが、.NET Framework / .NET Core 以外ならいい感じに ARM64 対応が進んでいます。 特に Electron 7 から ARM64 対応したのは結構インパクトが大きいと思っています。 Electron の公式ドキュメントに Windows on ARM 向けのチュートリアルが用意されていますが、微妙に古い情報だったので最新の Electron 8 と Visual Studio 2019 で試してみました。 と言っても自分は Win32 とか Windows on ARM に関する知識はあっても Electron 周りの知識はほぼないので、サンプルプロジェクトを全編通して利用しています。 ARM64 ネイティブで動くと、常駐するタイプのメッセージングアプリで有利
後悔しないための Azure App Service 設計パターン (2020 年版) - しばやん雑記
Azure App Service (Web Apps) がリリースされて 6 年、情報のアップデートを行いつつ気になった情報は適当にブログに書くという日々ですが、Regional VNET Integration や Service Endpoins が使えるようになって設計に大きな変化が出るようになったのでまとめます。 最近は Microsoft で HackFest を行うことも多いのですが、App Service をこれから使い始めたいという場合に、失敗しない構成を共有したい、知ってほしいという意図もあります。多いですが中身は単純です。 基本設定 64bit Worker は必要な場合のみ利用する FTP / Web Deploy をオフにする Always on を有効化する ARR affinity をオフにする HTTP/2 の有効化を検討する Health Checks の
ハワイに行って検証用に Surface Pro X を買ってきた - しばやん雑記
ずっと ARM64 な CPU が載った Windows 10 PC が動作検証用に欲しかったので、Surface Pro X の発売予定日に合わせてハワイまで行って買ってきました。 公式ブログや Panos は 11/5 に発売みたいに言ってましたが、実際には 11/6 の午後になるまで在庫は入っていませんでした。発売日に買えないとか印象悪すぎなので MS はマジで改善してほしい。 マイクロソフト Surface Pro X / Microsoft SQ1 / Office H&B 2019 搭載 / 13インチ / SQ1 / 8GB / 128GB / LTE / ブラック MJX-00011 マイクロソフトAmazon 購入したモデルは 8GB *1 RAM / 128GB SSD の一番安い $999 のやつです。動作検証用なのでメモリや SSD は大して必要なかったので、コスパ
Azure AD B2C のユーザーを Graph API を使って管理する - しばやん雑記
Azure AD B2C は後ろが Azure AD なのでユーザー情報は Graph API を使って色々弄れます。 Microsoft Graph を使ってユーザー情報を取得したりできますが、B2C に必要なプロパティが Microsoft Graph だとまだサポートされていないので、Azure AD Graph を使う必要があります。 調べた感じでは Azure AD Graph のクライアントはかなり古くて、今の時代に .NET Standard へ対応してない系なので使わない方が良さそうでした。 公式ドキュメントは自前で Graph API を叩くものばかりなので、それに従うことにします。そして Service Principal を作る部分からわかりにくかったので、メモがてら手順を残します。 Service Principal を作成する 以下の 2 つのドキュメントに Az
Azure AD B2C の知識が古かったのでキャッチアップし直した - しばやん雑記
ちゃんと触ったのが 2 年前と古く、ASP.NET Core も 2.0 の時だったので最新の情報でもろもろキャッチアップし直しました。基本的に Azure AD が嫌いなので B2C も Azure AD ベースでなければという気持ちが強いのですが、価格的に競合よりも使いやすいので。 とはいえ 2 年前から比べると全体的に使い勝手と機能が改善されていました。Azure Portal での設定もそれなりに分かりやすくなった気がするので、迷うことはあまりなかったです。 ロケーションに APAC が追加された（らしい） 今朝ツイートが流れてきて気が付きましたが、そういえば昔は日本を選べなかったのでした。 遂にAzure AD B2Cで日本リージョンの選択が出来るようになりました。 #AzureADB2C #AADB2Chttps://t.co/RqpyTp6Zeb— Naohiro Fujie
ASP.NET Core / Azure Functions で App Configuration と Key Vault を使って設定を一元化する - しばやん雑記
アプリケーションが 1 つとかの場合は App Service の App Settings や Connection Strings を使って設定すれば良いのですが、数が多くなったり環境が増えてくると大体管理しきれなくなって破綻する傾向にあります。 Infrastructure as a Code の考えで ARM Template や Terraform を使って App Settings を管理するのも良いですが、設定値はインフラというよりアプリ寄りなのでちょっと違うかなという気もします。なので Azure App Configuration と Key Vault を使います。 基本的な方針は App Service 側には必要最低限かつ最初以外ほぼ変更されないものだけを残します。今回であれば App Configuration と Key Vault のエンドポイントや、App
.NET Core 3.0 で WinForms / WPF を使う場合は実行ファイルのパスに注意 - しばやん雑記
.NET Core 3.0 では WPF や WinForms が使えるようになっていて、配布時には大体 Self-contained かつ Single-file executables としてパッケージングするのが一般的になるはずです。 Desktop Bridge を使って APPX / MSIX を作るのに近い形ですが、よりカジュアルに扱えます。 単体の exe ファイルだけ配布すれば、実行環境に .NET Core がインストールされていなくても動作するので便利ですが、以下のように自分自身のパスを取ると挙動が .NET Framework の時と異なっています。 using System.Windows.Forms; namespace WindowsFormsApp1 { public partial class Form1 : Form { public Form1() {
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
