Azure AD B2C を使ってローカルアカウントのサインアップを実装するのが非常に簡単なのですが、用意されているユーザーフローでは登録時に使用したメールアドレスを変更出来ないという問題が出てきます。 プロフィールの編集やパスワードのリセット機能はありますが、メールアドレスを変更することは出来ないためアプリケーション側でどのように対応するかが課題となってきます。とはいえ、完全にメールアドレスを変更できないというわけではないので、メールアドレスを変更する 2 種類の方法を紹介します。 メールアドレスの変更ポリシーを追加 1 つ目の方法は公式サンプルでも提供されているカスタムポリシーを利用した方法です。一般的なメールアドレス変更フローと同じように、まずはメールアドレスが正しいか確認コードを送信後に実際に変更を行うので入力間違いの可能性が低くなります 具体的なメールアドレスの変更フローは以下の
数年前から WinQuickLook という Windows アプリケーションを趣味で開発しているのですが、内部実装をガラッと変えた新バージョンの開発進捗が著しく悪いことに悩んでいました。現在 V4 というソリューションで絶賛開発中となっていますが、リリース日は未定という状態です。 このアプリケーションの開発を加速させるために、ViewModel を用意するより簡単な方法を求めていました。 初期バージョンは Windows Shell 周りの実装に力を入れていたので、UI 周りは Window が 1 つでボタンが数個ある程度だったため、大体はコードビハインドを使って書いていたのですが、V4 を機に MVVM で作ろうとしたところ余りにも面倒すぎて止まっているのが現状です。 Window が 1 つのアプリで ViewModel を分離して、更に MVVM フレームワークの導入とかそっちの
Build 2022 で発表されてから音沙汰がなかった Windows on ARM 開発 PC である Project Volterra ですが、突然 Windows 開発キット 2023 として発表されて、なんと日本でも発売が開始されたので購入しました。 こういった開発者向けデバイスが最初から日本でも発売されるのは珍しい予感です。 日本の Microsoft Store では価格を巡って混乱がありましたが、どうせキャンセルされると分かり切っていたので、正規の料金になったタイミングで購入したところあっという間に届きました。 あくまでも開発者向けという扱いにいるので外箱は段ボールそのままでしたが、本体は Surface と同様に質感が高く、コンシューマ向けにもそのまま発売して問題ないレベルだと感じています。 スペックについては以下の公式ドキュメントに一通りまとまっていました。最新の Win
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
GW なので趣味アプリの開発を行っていると、音楽ファイルに保存された曲情報を取得する必要が出てきたので、Windows Property System を使って実現したという話です。 曲情報というのは以下のようにファイルのプロパティから確認出来るメタデータのことです。 単純にファイルからメタデータを読み込むだけなら TagLib# というライブラリを使うと、特に難しい処理が必要なく読み取ることが出来ます。しかし最近はアップデートがほぼ止まっていて、偶に PR はマージされていますがリリースがされていない状態が続いています。 そういう経緯もあり、別の方法を検討した結果 Windows Property System に辿り着きました。 Windows Explorer やファイルのプロパティから確認出来る各種メタデータは、Windows Property System という統一されたインタ
少し前に 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 へのログインを行いつつ同時に発行されるアクセストークンを利用して、別に用意された API を実行したいというシナリオが存在します。 Microsoft Graph API を呼び出す場合はアプリケーションに許可するスコープを追加すればよいですが、自前で用意した API の場合にはまず API を公開するという設定が必要になります。 公式ドキュメントでも Web App から Web API を呼び出すシナリオが紹介されていますが、Azure AD にアプリケーションを登録するあたりは若干省略されていてわかりにくいです。 最近は Azure AD の設定を Azure Portal からではなく Terraform で全て行うブームが個人的に来ているので、今回も Terraform
少し前に 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 経
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 Light-up というハッカソンを行うことが多いのですが、Azure Functions を使う場合には必ずこの辺りは毎回説明するようにしています。要するに Azure Functions の利点・特性を理解して賢く使いこなそうという話です。 Binding / Trigger で実現出来ないか考える Function の実装は出来る限り小さく保つ リトライのしやすい実装を重視する 最新の .NET での作法に沿ったコードを書く Graceful Shutdown に対応したコードを書く 機能単位で Function App プロジェ
Build 2020 では App Service に関する話は非常に少なかったですが、唯一大きなリリースとしては Static Web Apps がありました。名前の通り静的コンテンツをホスティングするためのサービスですが、同じドメインで API (Azure Functions) が付いてくるのが特徴です。 詳しくは Daria の公式ブログや三宅さんの記事を読んでおいてください。このエントリではその辺りの紹介は全くしないので、知識がある前提で進めていきます。 自分は Static Web Apps がどのように構築されているのかのが気になるので、現在分かっていて触れる範囲で内部アーキテクチャを探ってみました。当然ながら非公式ですし、正しい保証はありません。 Static Web Apps でお手軽ホスティングしたい人には必要ないエントリです。普通は気にせずに GitHub からサクサ
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 (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 の
ちゃんと触ったのが 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
アプリケーションが 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 では 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() {
Durable Functions v2 beta 2 で Durable HTTP という機能が追加されました。クリス氏が Tweet で説明しているように、アクティビティ関数無しでよい感じに 202 Accepted のポーリングを行ってくれる便利機能です。 非同期処理の開始を 202 Accepted で通知して、完了したかどうかを Location ヘッダーで返した URL で確認するパターンを、全く意識させずに扱えます。 A quick summary of the capabilities of "Durable HTTP": * New CallHttpAsync APIs in orchestrator function * Automatic client-side async HTTP 202 polling * Built-in support for Azure M
今朝出てきた Azure の新しいアプリケーション向けサービスの Azure App Configuration が、今持ってる課題をいい感じに解決してくれそうなので、プレビューのうちに一通り触っておきました。 普通は ASP.NET Core の Configuration Provider や ASP.NET の Configuration Builder を使って触るはずなので、基本的な部分はドキュメントだけで十分です。なので特に触れません。 REST API のドキュメントは GitHub に用意されていました。Provider が叩いてる API なので、よくわからない設定や挙動があった場合はこっちを読めば大体解決します。Consistency Model の話は興味深いですね。 App Configuration で解決できそうな課題として、複数の App Service や
最近はまあまあ Cloud Services (Web Role / Worker Role) からの移行という話を聞くようになってきましたが、大体のケースで Service Fabric への移行を勧められているようです。 正直言ってこの提案は全くの見当外れであるケースが大半でしょう。何故なら現状 Cloud Services を使っているアプリケーションは、そもそもマイクロサービスに適した形になっていないことが多いからです。従って移行先としては最初に App Service が検討されるべきです。 1 VM に 1 アプリケーションという構造でマイクロサービスとか、難易度が高すぎるので当たり前です。提案した人は Cloud Services と Service Fabric の違いを全く理解してないのではないかと思ってしまいます。 既存サービスの Cloud Services からの移
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
