希望是最淺顯易懂的 RxJS 教學
前言 關注 RxJS 已經好一段時間了，最早知道這個東西是因為 redux-observable，是一個 redux 的 middleware，Netflix 利用它來解決複雜的非同步相關問題，那時候我連redux-saga都還沒搞懂，沒想到就又有新的東西出來了。 半年前花了一些時間，找了很多網路上的資料，試圖想要搞懂這整個東西。可是對我來說，很多教學的步調都太快了，不然就是講得太仔細，反而讓初學者無所適從。 這次有機會在公司的新專案裡面嘗試導入redux-observable，身為提倡要導入的人，勢必要對這東西有一定的瞭解。秉持著這個想法，上週認真花了點時間再次把相關資源都研究了一下，漸漸整理出一套「我覺得應該可以把 RxJS 講得更好懂」的方法，在這邊跟大家分享一下。 在開始之前，要先大力稱讚去年 iT 邦幫忙鐵人賽的 Web 組冠軍：30 天精通 RxJS，這系列文章寫得很完整，感受得出來作者下了很多功夫在這上面。看完這篇之後如果對更多應用有興趣的，可以去把這系列的文章讀完。 好，那就讓我們開始吧！ 請你先忘掉 RxJS 沒錯，你沒看錯。 要學會 RxJS 的第一件事情就是：忘記它。 忘記有這個東西，完全忘記，先讓我講幾個其他東西，等我們需要講到 RxJS 的時候我會再提醒你的。 在我們談到主角之前，先來做一些有趣的事情吧！ 程式基礎能力測試 先讓我們做一個簡單的練習題暖身，題目是這樣的： 有一個陣列，裡面有三種類型的資料：數字、a~z組成的字串、數字組成的字串，請你把每個數字以及數字組成的字串乘以二之後加總 範例輸入：[1, 5, 9, 3, ‘hi’, ‘tb’, 456, ’11’, ‘yoyoyo’] 你看完之後應該會說：「這有什麼難的？」，並且在一分鐘以內就寫出下面的程式碼： const source = [1, 5, 9, 3, ‘hi’, ‘tb’, 456, ’11’, ‘yoyoyo’]; […]
一次搞懂OAuth與SSO在幹什麼?
一次搞懂OAuth與SSO在幹什麼? 最近的Line Notify、Line Login，以及前一陣子的Microsoft Graph API，全都使用到了OAuth作為用戶身分驗證以及資源存取的基礎。但很多讀者會卡在OAuth的運作流程上，根本的原因是不理解OAuth到底是幹嘛的?其存在的目的為何?以及如何應用? 因此，我想花一個篇幅，盡可能短的介紹一下OAuth與SSO，但，與坊間文章不同的是，我希望從應用情境的角度(而非技術)切入談這件事情，冀望能夠讓開發人員對OAuth有個最基本的認識。 OAuth的背景 我們回頭看Line Login與Line Notify中的例子，OAuth在這邊最簡單的應用情境，就是身分驗證。典型的情境中有幾個角色，分別是: 網站或App的開發單位 : 也就是各位開發人員 OAuth服務的提供者(Provider) : 也就是Line(或Google、Microsoft…etc.) 終端用戶(End-User) : 網站使用者、Line使用者、消費者、客戶…etc. 上面這三者的關係是什麼？ 當我們建立一個網站（例如Pc Home購物）、或App(例如一個手機遊戲)，都非常有可能需要建立一組會員機制，這些機制包含: 登入（包含身分驗證，帳號、密碼保存…等） 個資管理（用戶名稱、地址、電話、暱稱、手機…等) 以往，幾乎都是每一個網站自己做一套，但這樣有很多麻煩事，首先用戶要記得很多組帳號密碼，而每一個網站都自己搞一套會員機制，網站開發人員自己也很辛苦，加上最近這幾年大家都很重視個資，網站儲存（保管）了很多帳號密碼與個人資料，總是會有被駭的風險。因此，這十年來，很多大廠開始提供登入（與身分驗證）機制服務。 也就是說，小網站你不用自己做登入和會員管理了，你連過來我這邊，我是大網站，我已經有幾百萬上億的用戶，(例如全台灣都用Line)，而且早就做了超級安全的會員管理機制，你這小網站何必自己做會員管理呢？你跟我連結不就得了，我大網站來幫你管理個資，提供你登入的服務，你把會員資料通通存我這裡，用戶也不需要記得很多組帳密，只需要記得我大網站的帳密，一樣可以登入你小網站(或稱為第三方應用）來使用你提供的服務，這樣皆大歡喜。 因此，大家就這麼做了。 但提供這樣服務的大廠越來越多，Google、Microsoft、Yahoo…都提供了這樣的服務，導致小網站為了對使用者更貼心，可能要同時連結上很多這種提供身分服務的大網站，如果每一家連結方式都不同，就很煩。因此，業界就開了幾個會，共同決定了一套工業標準，就是OAuth了。 有哪些功能？ 所以你會發現，基本上網站開發人員有兩種身分，一種是OAuth服務的提供者(像是Google、微軟、Line)，另一種是OAuth服務的使用者，像是一般的小網站(trello)。而終端用戶只需要在大網站申請過帳號，就可以登入小網站來使用服務。 但，大網站當然不能給你(小網站)用戶的帳號和密碼，否則多麼不安全呢?因此OAuth工業標準讓服務提供者(大網站)透過一種標準的作法，在用戶驗證過身分之後，提供一組會過期的令牌給小網站，這就是token。 小網站拿著這個令牌，就可以跟大網站取得用戶的個資，或是其他需要的資料。小網站也可以拿著這個令牌，跟大網站確認該令牌是否已經到期。 所以，整個流程大概是底下這樣: 由於上述過程中的(2)，登入畫面是大網站提供的，因此你小網站不會得知用戶的帳號密碼，大網站只會在登入成功後，把一個具有有效期限的Token傳給你小網站，一旦你需要存取用戶的資料，就拿這個token去跟大網站溝通。 當然，實際上的OAuth操作步驟又更複雜，如果你參考我們前面介紹的Line Login那篇，就會知道，用戶被引導到大網站完成登入之後，你小網站是無法直接取得token的，而是取得一個code，再去用這個code跟大網站換得一個token。為何要多這一道手續?因為，網際網路是個不安全的所在，在網路上傳遞的任何東西，都可能被路上經手的路由器或其他設備給擷取、偽造、變更，因此要確保安全，得更加小心一點。 因此一般的OAuth流程，其實應該長得像是底下這樣(這是微軟Graph API的OAuth Auth Authorization Code Flow流程) : 還有更複雜的、更進階的。 如果大網站除了提供用戶的個資之外，還要可以讓小網站有權限做一些額外的事情，像是變更用戶大頭照、取得用戶上傳的檔案、幫用戶book一個行事曆…這都是Office 365/Google Apps裡面典型的情境，如此一來，終端使用者(end-user)可能就要授權小網站，到底能夠使用該用戶在大網站中多少資料，也就是大網站的用戶要賦予小網站多大的權限，來存取該終端用戶的個資? 這部分，一般稱之為 Permission Scope。 所以，OAuth除了提供登入身分驗證之外，也逐漸開始負擔了網站合作之間的授權管理功能。 好，現在回過頭來看，請參考Line Login與Line Notify這兩篇中的例子，你會發現一開始我們都只是組出一個URL，來取得Authorization […]