講到多帳戶切換系統，通常你只會在一些類似 AWS 或者 Google 那樣大規模的系統裡面才會看到，然而這並不是沒有原因的。因為有時候部分功能為了權限上的分別，不少人比起想要設定一個擁有多權限群組的用戶，反而會比較喜歡以帳戶的方式來使用不同權限群組的作業環境。
單用戶多權限群組設計
原先的 ArozOS 採用多用戶多權限群組的設計，簡單來說就是每個用戶都可以加入一個或以上的權限群組，而這個用戶能做的事情和存取的儲存裝置就是 UNION of 所有的權限群組。假設群組 A 只能存取 A 的儲存池，群組 B 只能存取 B 的儲存池，那一個用戶加入了 A 和 B 的群組之後便能存取 A 和 B 兩個儲存池的資料，並在此中間自由移動和開啟檔案。
然而，不知道是不是這設計對於現代人來說太複雜了，很多人就是不會用，然後問我到底要怎樣才可以建立更多自用的使用者帳戶。建立之後他們又會來問到底要怎樣才可以把檔案在用戶之間移動，我就一整個（嗯？？？
多用戶單權限群組設計
所以後來我在跟用戶訪談的時候，發現其實他們比較多在用多用戶單群組的用法。簡單來說，就是一個用戶只有一個權限群組，當他們想要存取另一個權限群組的資料的時候，他們便會登出原先帳戶並登入另一個帳戶。這用法通常是用來處理一些對外的服務（例如 www 的帳號來處理跟 web service 相關的檔案），但是用在 cloud desktop 上的這種要求我猜我應該是第一個 implement 的說？
所以為了體驗這種奇怪的使用方法，我特別在 test bench 上架了一個網站，讓 www 帳戶來保存檔案。
然後就開始設計帳戶切換的邏輯。首先，一般的帳戶切換做法是使用 client side cookie / session 對每個帳戶進行登入，然後讓用戶可以自由切換在該 browser 上任何未過期的 login session。然而，在 ArozOS 上這有點不太可行
- ArozOS 的 authentication 是基於 cookie 而非 localStorage。如果設計改了的話對一些依賴 legacy login API 的系統會帶來嚴重問題
- ArozOS 是網頁桌面系統，相比起其他網頁的 stateless 設計，ArozOS 的桌面是 stateful 的，而且整個狀態是儲存在伺服器端
- 部分用戶在 ArozOS 上使用 oAuth / LDAP 作為登入認證伺服器，加上之後有打算加入 Cluster Authentication System 等伺服器端較複雜的結構，在客戶端上儲存登入狀態可能比較難做到跨伺服器間的 user state transfer
所以結合上述原因，我們最後採用了一個叫 Switchable Accounts Pool 的設計。
Switchable Accounts Pool (SAP) 是一個我們設計出來的實驗性東西。它的功能大概就是以一個 pool id 來對應一堆可以切換的帳戶，而這些帳戶又會有 main / secondary 的關系，讓帳戶的登出的時候在伺服器端對該瀏覽器的登入狀態進行切換。
一開始，當主帳戶登入的時候，一個在伺服器端的 SAP 便會被建立。Creator 的名字就會寫著是主帳戶的名字。之後，用戶可以透過登入 sub-account 以取得在這個 session 結束之前，可以不斷切換到 sub-account 的權利。
當 Sub account 登出的時候，由於 main account 的 session 仍存在，因此伺服器端會直接改寫 User 的 login cookie 到原先的 creator account。
而當 Main account （即 SAP 的 Creator）登出的時候，伺服器端便會直接 discard 整個 SAP 以保護其他 sub-account 的安全（非法透過登入 sub-account 以取得 main account 的存取權）。
在邏輯搞清楚之後，剩下的便是把功能寫出來了。這裡只是一點簡單的 Go programming，技術上沒甚麼特別的所以我就不再詳談。
在一些特殊情況下，例如說 main account 的 login session expire 但是 SAP 的 session 還沒 expire ，使用者便會在登入界面看到這樣的一個 popup，讓他可以快速回復之前登入過的 SAP ，不用再重新登入所有帳戶。
就是這樣，現在的 ArozOS 又多了一個超級好用的帳戶切換功能了。那些習慣用 G-suit 的人大概應該會感到 実家のような安心感 （回到老家般的安心感）吧？
