發表文章

目前顯示的是 2月, 2023的文章

使用Azure Cloud Shell

圖片
Cloud Shell是雲端的CLI環境,你可以從Azure Portal上直接啟動該環境: 這麼做的好處是,你即便在本機電腦(筆電)上沒有安裝AZ CLI,也可以透過網頁即可以命令列模式來管理雲端的資源。 另外,使用雲端版本的CLI還有一些額外的好處,諸如: 無須登入(az login…),因為你使用Cloud Shell的時候,本來就有登入Azure Portal。 無須安裝其餘CLI工具或SDK,諸如 git, dotnet , python, docker, kubectl…這些內建通通都有。甚至,還有網頁(陽春)版的VS Code!!! 底下影片介紹如何操作Cloud Shell,第一次進入的時候,會讓你選擇一個Azure 儲存體(Storage),並且選擇Linux或Windows環境: 所以,Cloud Shell內建就有Windows與Linux雙模式,你可以透過左上角的選項切換: 其實,Cloud Shell本身就是一個儲存體,你可以在該環境中建立資料夾,新增檔案,除非你刪除或無法存取該訂閱,否則這些資源都會保留在雲端儲存體中: 一般來說,如果要對雲端的Azure資源進行操作,我們常常會直接在Cloud Shell中,下CLI或Power Shell/Bash指令,省去在用戶端還需要安裝 CLI 並且做 az login 動作的麻煩。 有操作Azure的開發或維運人員,是一定得要試試看這個好工具的。

使用AI服務擷取文章重點

圖片
在Azure Cognitive Services 服務當中,文字分析(Text Analysis)服務可以針對用戶上傳的文字進行剖析,例如『文字情緒分析』、『關鍵字詞擷取』、『文字摘要』…等。這些服務都以rest api的形式出現,你只需要先取得呼叫API所需的金鑰與端點即可。 底下影片展示如何從 Azure Portal 建立『文字分析服務』,並且找到金鑰與端點: 有了金鑰與端點後,就可以透過程式碼來呼叫其功能。 例如其中的『擷取文章摘要』,是文字分析服務中剛推出沒多久的新功能,可以針對一篇文章、一段文字,抓取其中的重點。 呼叫的endpoint如下: POST { Endpoint } /language/:analyze-text?api-version = 2022-10-01-preview 除了header要傳遞key(金鑰)之外,body要符合底下json格式: { "displayName" : "Document ext Summarization Task Example" , "analysisInput" : { "documents" : [ { "id" : "1" , "language" : "zh" , "text" : "(要分析的文章)" } ] } , "tasks" : [ { "kind" : "ExtractiveSummarization" , "taskName" : "Document Extractive Summarization Task 1" , "parameters" : { "sentenceCount" : 3 }

使用Azure APIM 中的 Polices微調API的行為

圖片
最近這幾年,愈來愈多的網站改以前後端完全分離的架構來開發,而微服務盛行,許多後端應用、AI服務、甚或是商業邏輯,都改以WebAPI的方式來實作,更別說為數眾多的手機行動裝置App也需要以呼叫後端API的方式與伺服器端溝通,來完成各種功能。 因此,API開發成為最近幾年的顯學,API First也在許多場合被提起。Azure的APIM服務,就在這樣的情況下誕生了。 使用APIM服務 Azure APIM可以幫我們把企業內部的多組API打散或重新包裝,改以同一個endpoint對外,好讓使用者更方便使用,讓管理者更方便控制與管理。 另外,採用APIM還有一個好處,我們可以隔開用戶和真正的API,這樣除了可以保護後端真正的API,也可以在用戶透過APIM呼叫後端真正的API前,可以對往來(與回覆)的數據做一些加工處理,已達成我們需要的安全性或是API行為的改變,也更容易統一的進行全縣控制…等。 建立APIM 底下影片示範如何建立APIM服務,請注意APIM服務的建立,會花比較長的時間,可能會長達半小時以上: 完成之後,就可以建立好APIM服務了。 建立API集合 建立好APIM服務之後,接著可以在Azure Portal中,建立API集合,前面說過,我們會把實際上開發好的API,先整理成API集合,然後再包裝成產品(Product),釋出給客戶。 底下的說明,我們將示範如何將現有的API(在具備spec definition的狀況下),整理成待會要釋出的產品。我們以底下這組微軟官方的測試API為例: https://conferenceapi.azurewebsites.net?format=json 如果你點選上面這個網址,會發現,它出現的是json格式的API規格: 這是標準的 swagger 2.0規則,一般我們撰寫WebAPI之類的後端API服務,都可以透過工具自動產生這些規格文件。若具備這些規格文件。 你可以直接將API透過Import的方式匯入,請看底下操作影片: 從上面的影片當中,你會看到,我們利用 swagger 的json規格定義,把上面的微軟測試API,重新透過APIM封裝,建立另出了一組 endpoint 。 你可以發現API中有一個 GetSpeakers 方法,當我們運行(呼叫)這個方法,會以JSON格式回傳

使用Computer Vision中的OCR文字辨識功能

圖片
OCR(Optical Character Recognition)指的是識別圖片中的文字,如果你先前已經成功使用Computer Vision API做影像識別(Image Analysis),那使用Computer Vision API做OCR肯定也難不倒你。 請參考同樣的文件: https://westus.dev.cognitive.microsoft.com/docs/services/computer-vision-v3-2/operations/56f91f2e778daf14a499f20d 你會發現,ORC的API與先前我們介紹過的影像分析幾乎一模一樣,唯一差別是要給定的endpoint URL,最後的結尾是『ocr』。設定如下: 另外,如果要辨識中文,建議要給定language這個queryString參數,值為『zh-Hant』。 有這些資訊就夠了,我們一樣透過postman來測試,關鍵的資訊如下: 關鍵資訊 值 endpoint https://你的endpoint.cognitiveservices.azure.com/vision/v3.2/ocr?language=zh-Hant Ocp-Apim-Subscription-Key(http Header) 你的key Http body {“url”:“要辨識的圖片url”} 透過這些,我們就可以嘗試辨識了。透過Rest API將要辨識的有像位置(url)傳遞過去,辨識的結果會以JSON回傳。 操作影片如下: 影片中,辨識的文件是底下這張圖: 該圖片的網址為: https://i.imgur.com/PWQDiRj.png 你也可以自行試試看,你會發現,中文的辨識度其實非常高,幾乎正確的辨識出每一組文字。 回傳的物件是JSON格式,由於圖片上的文字可能有橫有直,辨識出的結果會是以 Regions, Lines, Words, Text 為結構回傳: 透過 computer Vision 中的 ocr API,取得圖片上的文字變得非常輕鬆。 tags: 電子書 - Azure Cognitive Services

Azure Cosmos DB 建立與使用

圖片
什麼是非關聯式資料庫? 最近這幾年,非關聯式資料庫開始成為許多大型系統的架構考慮之一,原因有很多,但歸根究底核心原因我覺得是『全球化』。 過去企業(即便是大型的全球化企業)在建立資訊系統的時候,大部分都是以集中式為主的架構,也就是說,核心的資料庫只會有一份,頂多加上異地備援機制。 在傳統的企業營運需求上,這樣的設計完全沒問題,而且關聯式資料庫的特性就是 ACID ,有著結構清晰的資料表,經過正規化,存入的資料欄位都是固定的,這確保了資料的高可靠性與正確性,對企業應用系統來說,恰是所需。 但對於全球化的網際網路需求,可就不一定了。 當前的關聯式資料庫儲存資料有幾種類型,像是底下這樣: 你發現,這些資料的結構跟過去方方正正的資料表很是不同,現實生活中,有很多類似這樣的資料,例如: 若我們想表達一位用戶的朋友、資源、行事曆、檔案…等資訊,結構上就很可能不是傳統關聯式資料表所能表達的,這時候非關連式資料庫就開始派上用場。 除此之外,另外一個主因是 --『同步一致性』。 資料的同步問題 在企業內,資料的一致性似乎很重要,但一致性並非沒有代價,假設資料庫採分散式架構,在全球3-5個點都有資料庫,彼此之間進行同步抄寫。 這樣的架構底下,要維持一致性是很困難的,這也是大部分企業應用都採集中式架構的原因,但集中式架構最大的缺點是,如果總部斷線,就意味著全球各地區都別運作了。 但真實世界中,我們真的需要在全球有數個彼此同步抄寫的資料庫嗎? 過去沒有,但現在可能到處都是,最明顯的例子就是像FB之類的社群網站。 社群網站每秒中有數以萬計的留言對話,可能同時需要存入資料庫,如果採用傳統的關聯式資料庫,又是集中式設計,很可能根本無法運作,因為資料庫的loading太大了,光寫入資料就沒時間了,更何況還要承擔全球性的讀取。 所以非常有可能採用全球數個資料庫彼此抄寫的狀況,但這時候,『資料同步』將是個問題。 我鍵入一筆留言,在台灣的資料中心可以即時看到並回應,但在地球另一端的資料庫中卻可能還沒出現,因此我在國外的友人會隔一段時間才看到(需要等資料抄寫過去),然後他才能回應,同樣的當國外的友人回應,在台灣的我可能也不會立刻看到,而會延遲一段時間。 這就是分散式資料庫可能會碰到的問題。 這對於開發人員來說,是兩難。因為 集中式效率會變低,分散式會導致資料的精確性或

建立與使用Computer Vision(電腦視覺)服務

Computer Vision 是Azure Cognitive Services中,一組作影像識別辨識的API,功能強大,可以進行圖片內容(意義)的識別。也可以找出圖片中的人臉,並且判斷年紀、性別。還可以進行OCR,找出圖片中的文字…等,該服務的官方網站位於: https://learn.microsoft.com/zh-TW/azure/cognitive-services/computer-vision/ 申請使用金鑰 使用上很簡單,可透過SDK或Rest API來呼叫,由於我們要透過程式碼來呼叫使用該服務,因此得先從Azure平台上申請一組Key,並取得Rest API的Endpoint。 請參考影片中的操作: 上面的影片中,你看到我們申請好Computer Vision服務,並取得金鑰與端點的位置。 使用Rest API呼叫識別服務 取得金鑰與端點之後就好辦了,參考官方文件,你會明白如何呼叫,以及API的詳細使用說明。 簡單的說,我們可以把圖片上傳給剛才我們建立好的服務端點(endpoint),然後雲端AI服務就幫我們辨識出圖片的結果(以JSON回傳),而呼叫的時候,需要一個key,僅此而已。 我在上課時,會刻意帶學員從網上找到底下這分文件,並且整個看過一次: https://westus.dev.cognitive.microsoft.com/docs/services/computer-vision-v3-2/operations/56f91f2e778daf14a499f21b 因為呼叫方式雖然常常快速迭代改版,但其實Azure Cognitive Services中幾乎每一個服務都有清晰的文件,只要能找到並看懂文件,抓到重點,呼叫上非常方便。 底下影片介紹你如何在文件中找到幾個關鍵,例如呼叫的參數、呼叫時的http method,以及上傳檔案給endpoint的方法: 看懂文件,你應該知道如何透過rest api呼叫該服務了(使用SDK的方式以後再談),接著,我們可以透過免費的postman工具,來嘗試呼叫該影像辨識服務。 postman是網路上免費可下載的 rest api呼叫測試工具,非常簡單好用。下載位置位於: https://www.postman.com/ 取得postman之後,就可以透過該工具,來

使用Azure Redis Cache

圖片
Cache被稱作快取或緩存,是一種提高運作效率的資料存取方式。 Redis Cache本身是一套open source軟體,以記憶體作為緩存資料的位置,我們可以把一些時常(或大量)需要被讀取,或是不常更新的靜態資料,從傳統資料庫(或其他儲存體)複製一份放入Cache DB中,以便於提高讀取時的效能。 因為資料庫或一般硬碟儲存體的讀寫是物理性的IO存取,而Redis Cache則是記憶體的讀取,當有大量的讀取發生時,位於記憶體的Redis Cache效能會明顯的比實體的讀取提高很多。 一般來說,典型的Cache機制使用方式如下: Cache中的資料可能會定時或依照你所設定的條件更新,以便於抓取較新版的資訊。 在Azure PaaS平台上,也有現成的Redis Cache服務,你可以透過底下CLI指令來建立Azure Redis Cache服務: #設定資料中心區域 $myLocation = "eastasia" #建立資源群組 az group create -n test-redisdemo-rg -l $myLocation #設定redis cache名稱(取亂數以避免重複) $redisname = "testredis" + $( get-random -minimum 10000 -maximum 100000 ) #建立redis cache az redis create -l $myLocation -g test-redisdemo-rg -n $redisname --sku Basic --vm-size c0 結果如下(回覆JSON): 當然,也可以透過底下網址,從Azure Portal建立Redis Cache: https://portal.azure.com/#create/Microsoft.Cache 建立畫面如下: 建立完成之後,基本的使用就很簡單,你只需要從Portal上找到 Redis服務的 ConnectionString(位於存取金鑰),即可操作該Cache: 有了ConnectionString後,利用SDK,透過ConnectionMultiplexer.Connect()方法,即可存取該料庫: var cache

Azure Strage中的Queue機制

圖片
Storage Queue是相對Service Bus而言較為簡單便宜的queue解決方案,以Storage為儲存體,在Storage中就可以直接建立: 透過程式碼操作的方式也很簡單,先找到key: 接著透過SDK,建立一個QueueClient物件即可操作: public static void CreateQueueClient ( string queueName ) { // Get the connection string from app settings string connectionString = ConfigurationManager . AppSettings [ "StorageConnectionString" ] ; // Instantiate a QueueClient which will be used to create and manipulate the queue QueueClient queueClient = new QueueClient ( connectionString , queueName ) ; } 請注意上面的程式碼使用了 Azure.Storage.Queues 套件,因此你必須從nuget安裝: dotnet add package Azure.Storage.Queues 我在github上有一個範例,讀者可以在建立好queue之後,透過git clone下載該範例運行: git clone https://github.com/isdaviddong/az204-DemoAzureStorageQueue.git 運行的流程請看底下展示影片: 身為一個簡簡單單的FIFO容器,Queue看起來沒啥大錄用,不過就是放放資料讓資料排隊慢慢處理,但記得前面提過的 Load Leveling嗎: (from Microsoft architecture center) 如果用的好,Queue可以幫你省下大筆 做 scale out的經費呢,總有人覺得雲端貴,但其實,往往

架構設計中常見的Message與Event機制

圖片
古時候的應用程式,大多是一座孤島,作業系統載入一個應用程式(例如計算薪資),當它運行完畢,結束,就退出作業系統,釋放資源,把控制權交出來。當時的應用程式架構很簡單,就…把功能通通寫在一起,完畢。 時間快轉到今年,過去就表過不提,自從有了網路(特別是網際網路)之後,應用程式的架構開始愈來愈複雜。例如,現在很多Web應用程式是前後端分離的架構,後端採用Restful API,前端運行在瀏覽器上,透過javaScript(或某種js框架),與後端Restful API互動,彼此交互以完成一個工作。 這是近代初學者,最常碰到的應用程式架構。 但當應用程式的功能愈來愈多,我們當然不可能(也不需要)在『一個』應用程式當中,一口氣去完成所有功能,我們可以把應用程式切小,然後透過應用程式和應用程式之間的合作,來完成一個比較大的任務,這時候,擔任應用程式與應用程式之間資訊傳遞橋梁的事件(event)和訊息(message)就顯得非常重要了。 事件(Event)和訊息(Message)的意義 在這一篇的討論當中,你看到的『事件』和『訊息』這兩個字眼,大多意味著某種資訊 --> 像是一組JSON資料、一個文檔、或是一個XML資訊、甚至,只是幾個bytes的字串。 總的來說,『事件和訊息』就是 應用程式A 傳遞給 應用程式B 的某種資訊,主要的用途是 溝通 。例如用戶在前端網頁上購物,產生了一筆訂單,這筆『訂單』就是一個訊息,Web的前台系統,會把這個訂單,傳遞給中台或後台的其他程式,來處理出貨、扣庫存、帳務處理…等動作(功能)。 你或許有一個疑問,為何不在前台網站系統用戶產生訂單的那一刻,就扣庫存和安排出貨呢? 技術上可以,但實務上常常不是這樣的。因為不是所有的系統都是一體的,企業的系統可能是分階段、分廠商開發的,甚至可能根本是外購不同廠商不同開發技術的系統拼裝起來的,所以系統和系統之間的溝通,並不一定會發生在同一個資料庫裏面。而且這麼設計,會把系統個體之間的相依性綁得太緊,導致以後牽一髮動全身。如果我們把每一個功能(購物網站、訂單、出貨、庫存、發票…等)都設計成獨立的系統,有各自獨立的資料庫(儲存體或資料表),也都可以獨立運行,那在架構設計上,將會更加彈性和靈活(其實這也導致後來逐漸成形的微服務概念)。而這樣的設計,就會導致系統和系統之間,需要透過『訊息或事件』來

使用 Azure 中的 Service Bus 服務

Service Bus中文叫做服務匯流排,在使用 Service Bus 前,請先透過底下方式建立: 建立好 service bus 後,接著我們就可以透過程式碼來操作,昨天的文章中,我們提過可以透過 service bus 中的 queue機制,來做 load leveling 架構。至於如何存取 service bus, 我有參考az-204課程,寫好一個範例程式碼,位於github,你可以透過底下指令來下載: git clone https://github.com/isdaviddong/az204-ServiceBusLab.git 從 github上clone我寫好的範例之後,你可以替換其中的連線字串,並且透過azure portal在service bus中建立名稱為『az204-queue』的 queue,即可執行該範例進行測試: 從上面的展示中你可以看到,我們透過兩個console app,一個作為訊息(message)的發送方,一個作為接收方,成功地透過service bus的queue來傳遞訊息與溝通。 如此一來,你就可以實現先前我們介紹過的 queue-based load leveling等機制。

透過Azure App Configuration實現Feature Toggle

圖片
Feature Toggle有很多名稱,也常被叫做 Feature Flag, Feature Switch…但不管他叫什麼名字,都無損他在這個時代的重要性。 為什麼重要? 他為這個時代所面對的問題,提供了適當的解決方案,這些問題包含: 實現A/B測試 實踐金絲雀佈署 實踐高強度的頻繁交付 實踐不同環境上的自動化佈署 … 乍看之下,上面這幾件事情都跟Feature Toggle無關,但實則有很大的關連性。在說明前,我們先理解一下 Feature Toggle 是甚麼? Feature Toggle的建立 他是一個後台控制的開關,與我們的程式碼有所連動,簡單的說,就是在我們的程式中,加上一些簡單的if…then判斷敘述,然後依照這個開關在後台所設定的on或off,來決定是否要執行(啟用)某個功能。 這麼簡單的機制,為何和自動化佈署有關? 又為何可以幫助我們實踐 A/B 測試? 先談『高強度的頻繁交付』,以及『在不同環境上實現自動化佈署』這件事。 如果你對CI/CD或敏捷開發有概念,大概能夠理解近代軟體開發都希望能夠頻繁交付,頻繁的程度因團隊而異,高強度的頻繁交付,可能需要一天更版數次,而無論是一天更版數次,或是一周交付數次,都意味著開發團隊很可能每天多次合併程式碼,在這種狀況下,程式碼版控的多分支方案(例如gitflow)將變得不可行,而會慢慢收斂成單一分支(feature branch)或根本沒有分支的狀態,在這種狀況下,程式碼的整合和交付將可以變得非常頻繁。 但衍生出一個副作用,就是在這個狀況下,開發到一半的功能怎麼辦? 如果團隊需要急著修復用戶反饋的某一個bug, 必須立刻整合上版,但卻又同時需要等某幾個功能都做完,才能一次上線,這就產生了矛盾。 這時,feature toggle就會派上用場,它可以幫我們在正式環境上,先關掉不想開放的功能,等幾個具有相依性的功能都完成,再從後台一次打開開關放行。 這就是feature toggle在近代敏捷開發與CI/CD潮流下,非常重要的原因,因為它有效的分離了釋出(Release)與(Deployment)。 可以實現佈署(Deployment),但不開放(Release)功能的效果。 配合A/B測試 與 金絲雀佈署 你可能有聽過 A/B Testing,它指的是,我們會在p

好好使用Logic App, 沒事幹嘛寫程式?

圖片
不是所有東西都要寫程式的。 最近幾年,又開始流行No Code/Low Code Solutions,RPA(Robotic Process Automation, 機器人流程自動化)就是其中之一。 微軟在SaaS和PaaS平台都有相關的服務,M365的SaaS平台中,Power Automate就是RPA解決方案,可以讓power user用拖曳設計的方式,撰寫少量或幾乎不用撰寫程式碼,就可以完成一些自動化流程。 而PaaS平台上,就是Azure Portal中的 Logic App 。 什麼是Logic App 技術人員可以把透過Logic App,用拖拉組合的方式,把一個流程設計出來,定時或在特定事件發生時,觸發後續的一連串動作。例如,當用戶把檔案上傳到 OneDrive,就自動進行圖像的人臉辨識,然後把辨識結果發送mail給特定人,如今這樣的流程,你完全不需要寫一行程式碼即可以完成。 透過這樣的方式,你可以大幅的簡化人工作業流程,乍聽之下,它跟Azure Functions, Power Automate都很像,但還是有些差異,Azure Functions雖然有binding功能,但主要還是透過撰寫function code來進行核心邏輯的處理,而Power Automate比起Logic App則比較偏向於End-User用戶端,Logic Apps中的connector和trigger則比較偏向雲端服務的整合。 具體差異可以參考微軟官方文件『 Logic Apps、Functions、WebJobs 和 Power Automate 之間做選擇 』 建立Logic App服務 當你建立好一個Logic App服務之後,緊接著可以建立工作流程,底下影片展是如何在 Azure Portal 上 建立一個Logic App服務: 建立與使用Logic App自動化流程 建立好了服務之後,我們接著就可以建立一個流程,建立的過程中,我們需要選定 trigger 也就是觸發條件。 請看底下的例子,我們在用戶上傳檔案到 onedrive 的時候,觸發流程,然後透過 outlook connector 來進行後續的自動化動作,將上傳的檔案名稱與路徑寫入mail中發送給特定用戶: 從上面的設計展示影片中你可以看到,onedrive conn

使用Azure App Configuration處裡微服務與容器化的配置設定

圖片
應用程式大致都會有環境變數,一般來說,我們在做網站時,除了把環境變數或是資料庫連線字串…等這些設定資訊,存放在 WebApp 的 App Config(組態設定)中,我們還有幾種不同的選擇。 Azure上獨立的App Config服務就是其中之一,中文名稱叫做『應用程式組態』。 建立『應用程式組態』服務 你可以透過 Azure Portal 建立該服務: 比起一般的config服務,從上面影片建立該服務的過程中,你也看到了,它額外具備了雲端特有的『異地備援』、『虛刪除』…等功能,讓資訊的保存更加安全可靠。 此外,它除了組態總管(Configuration Explorer),還有功能管理員(Feature Management): 你只需要透過端點(endpoint)與金鑰匙(Key)就可以存取該服務。當然,存取的過程中,需要建立類似資料庫的連線字串: 保存在該服務裡的組態資料,都是以 key-valut pair 的形式被建立的,你可以透過組態總管來建立: 撰寫程式碼抓取config資訊 建立好組態資料,接著就是在程式碼中存取。要在程式碼當中抓取存放於雲端的config資料,也相當容易,我們嘗試建立一個console app來測試: md testappconfig cd testappconfig dotnet new console dotnet add package Microsoft.Extensions.Configuration.AzureAppConfiguration code . 上面這幾行CLI指令,會建立出一個 console application,並從NuGet引用’Microsoft.Extensions.Configuration.AzureAppConfiguration’套件。 然後,我們透過VS Code 開啟該專案,並且撰寫底下程式碼: using System ; using Microsoft . Extensions . Configuration ; using Microsoft . Extensions . Configuration . AzureAppConfiguration ; namespace appConfigTest { class

透過Azure AD實踐網站單一登入機制

圖片
無論是實踐單一登入(SSO)所需要的身分驗證,或是採用OAuth機制,讓用戶授權第三方應用程式來存取受管理的資源,都會從『建立一個應用程式』開始。 Google, 微軟, Twitter, LINE…都有自己的OAuth機制。Google 位於API Console, 微軟位於Azure AD,而LINE 則是使用LINE Login…這也是你常常會看到現在許多網站都有支援各種SSO身分驗證機制的原因: 在Azure AD註冊應用程式 底下我們以微軟的身分驗證機制,拿Web類型的第三方應用程式來做例子,這段影片,示範了如何在Azure AD上建立一個應用程式: 從上面的展示,你會看到我們在Azure Portal上建立好一個 App, 並設定Redirect URL,並取得App ID。建立時,身分驗證類型有四種: 分別是: A. 企業用,只支援該AAD所屬企業 B. 企業用,支援所有具有AAD的企業 C. 企業(to B)+個人(to C),上述B加上個人帳號( 例如hotmail.com , outlook.com , msn.com …等) D. 僅限個人帳號登入,例如 hotmail.com , outlook.com , msn.com …等 接著,我們要建立並取得待會Web應用程式需要進行身分驗證時,所需要的 App Secret: 另外別忘了,再次檢查設定好的redirect URL,測試階段我們先用 localhost: 完成之後,我們就可以來測試一下,如何使用OAuth的身分驗證機制來取得access token。 OAuth Authorization Code Flow 依照OAuth的Authorization code flow流程,我們的作業流程分成兩個階段, A> 第一個階段我們做身分驗證,並取得代碼(code), B> 第二階段再拿code去跟伺服器端要access token。 第一階段,我們需要提供底下這些資訊(剛才都已經蒐集到): App Clinet ID redirect URL 微軟AAD使用的 endpoint 為: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?respon

建立與使用Azure Storage Account(儲存體帳戶)

圖片
Azure Storage 是 Azure中主要的儲存體,擔任一切儲存的任務。Azure Storage本身具有四種不同的存儲形式,分別是: Files 可模擬SMB檔愛存取機制,類似雲端硬碟。 Blobs 適合存取各種檔案,類如影片、圖檔、文件、logs…etc. Tables NoSQL形式的資料儲存體。 Queue FIFO(先進先出的佇列儲存體) 典型的Storage durability形式有底下幾種: LRS(本地備援儲存體) - 單一資料中心內備援三份 ZRS(區域備援儲存體) - 將資料同步複寫至三個不同的區域。每個區域具備獨立的電源、冷卻和網路的不同實體位置 GRS(異地備援儲存體 - 基於LRS,再將資料以非同步方式複製到位於數百英哩外的另一個位置,實現真正的 異地 備援。 RA-GRS - 基於GRS加上可從異地支援讀取功能。 底下影片示範如何建立azure storage,並且建立一個 container,以及上傳檔案(blob)到container中。觀察影片中的操作,你會發現,當我們把 container的存取權限調整之後,blob檔案的URL就可以存取了,否則會變成找不到上傳的檔案: Container 的 匿名存取層級有三種: 無公用讀取權限︰只能讓有授權的用戶存取容器及其 Blob檔案。(此選項是預設值) 僅對 Blob 有公用讀取權限:您可以透過匿名要求讀取容器內的 Blob,但您無法匿名使用容器資料。 匿名用戶無法得知容器中有哪些blob檔案。 容器及其 Blob 的公用讀取存取權限:匿名要求可以讀取該容器中所有 Blob 檔案,也可以列出容器中有哪些blob檔案。 Shared Access Signature (SAS) 針對特定的 blob 檔案,可以產生具有SAS(簽章)的連結,可讓特定IP在特定時間內,存取該blob檔案。 產生SAS簽章的方式如下: 透過具有簽章的連結,可以在特定時間區間內,從特定的IP位置存取該blob檔案,是控制權限很好的方式。 參考資料: https://learn.microsoft.com/zh-tw/azure/storage/common/storage-redundancy