隨著作業系統的升級或發展過程,在當前安全威脅日益高張的年代,當然作業系統的相關安全性與設計也會隨之強化。
硬體的驅動程式是會跟作業系統 (OS) 直接作動的,所以從安全性的角度來看,隨著時間的推進而造成一些外部裝置的驅動程式過於老舊,沒有跟著新版作業系統的安全性設計而改版,產生與新版作業系統發生不相容問題,也不難理解。

但是就這樣把問題都推給微軟,說通通都是 Windows 11 的錯,這就很難令人理解了🤔
反觀果粉就不會有這種心態…很妙😏
隨著作業系統的升級或發展過程,在當前安全威脅日益高張的年代,當然作業系統的相關安全性與設計也會隨之強化。
硬體的驅動程式是會跟作業系統 (OS) 直接作動的,所以從安全性的角度來看,隨著時間的推進而造成一些外部裝置的驅動程式過於老舊,沒有跟著新版作業系統的安全性設計而改版,產生與新版作業系統發生不相容問題,也不難理解。

但是就這樣把問題都推給微軟,說通通都是 Windows 11 的錯,這就很難令人理解了🤔
反觀果粉就不會有這種心態…很妙😏
.NET MAUI 撰寫好 iOS 應用程式後,不外乎就是要發佈該 iOS 應用程式到 App Store Connect 當中,除非所寫的是專屬給企業內部使用的 iOS 應用程式。
而在 Xamarin 的時代就已經可以透過 Visual Studio 的介面操作,直接發佈 iOS 應用程式的 *.ipa 到 App Store Connect,詳情請看:
透過 Visual Studio 串接 App Store Connect 發佈 iOS App
https://dotblogs.com.tw/jamestsai/2020/06/05/Using-Visual-Studio-publish-iOS-App-to-App-Store-Connect
而微軟官方文件也有相關的撰寫:
如果根據 前篇 操作後有發現 macOS 所建立的憑證不受信任的話,請參考此篇處理。

開發 Apple 的 iOS 應用程式,若在 Mac 裝置安裝好 Xcode 時,就可以透過 Xcode 直接建立該 Mac 裝置的機器憑證,送至 Apple 的 Developers 網站當中以利後續使用 "iOS 裝置" 開發或測試應用程式。
甚至,後續要將 iOS 應用程式發佈至 AppStore Connect 當中,無論是要先進行 TestFlight 測試;或是對自己的 iOS 應用很有信心要直接送審,也都是需要先有 Mac 裝置製作的機器憑證,作為 iOS 應用程式發佈憑證才行。

也就是說無論要用哪種開發技術,想要發佈 iOS 應用程式到 App Store 都必須處理這檔事。
有一天赫然發現自己的網站使用 https 瀏覽時會被判斷為 "不安全" 的連線:

記得在憑證到期之前已經在 "D 家" 更新憑證了,怎還會變為 "不安全" 瀏覽呢?
本來在查找因為硬體的 Driver (驅動程式) 不相容 Windows 11 的困擾,所以就上微軟的官網看看要怎麼處理此問題,結果反而遇到了更奇怪的事情,居然連要在 Windows 11 的 "設定"→"隱私權與安全性" 要 "開啟 Windows 安全性" 應用都出現無法開啟的狀況😯

在 「替 Azure 的 App Service 網站設定自訂網域後掛上 SSL 憑證 (上)」 的篇章中,有提到如果購買憑證跟購買網域的單位、組織、或負責處理的人是不同的,會遭遇到驗證網域控制權的問題。

上圖黃標字寫了特別提醒,結果...有一天就遇上了😥
就說做人不要鐵齒了吧!
因為在測試使用 Microsoft EM + S 的 E5 試用時,要測試 Office 365 中的 Excahange Online 功能,這才發現 Microsoft EM + S 的 E5 授權不包含其相關功能...冏

難怪怎麼在 Outlook App 當中登入帳號都無法連線到 Exchange Online 呢(菸~~~
後來再認真的看了看相關的授權,如果選擇 Office 365 的 E1、E3 或 E5 授權,又或者選擇使用 Microsoft 365 的 E3 或 E5 授權,跟原本已啟用 Microsoft EM + S 的 E5 授權有 Office 365 服務的功能重複。
在這兩篇文章當中有
一個必要條件:
兩個網址要使用:
三個觀念要知道:
以上都捧友都清楚的話,即可繼續閱讀本文...
在這兩篇文章當中有
一個必要條件:
兩個網址要使用:
三個觀念要知道:
以上都捧友都清楚的話,即可繼續閱讀本文...