中文字幕 日本 在线 高清,久久精品国产99精品国,超碰人人香蕉,一区二区三区无码高清视频

SaaS平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置(saas平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置)

UIMS即統(tǒng)一身份管理系統(tǒng),可以認(rèn)為是多租戶架構(gòu)的升級版,通常是整個平臺賬號和權(quán)限管控的基礎(chǔ)性系統(tǒng),可劃分為兩級賬戶體系、基礎(chǔ)權(quán)限模塊和基礎(chǔ)信息模塊三大模塊。本文從這三個方面對UIMS進(jìn)行了分析闡述,一起來看一下吧。

SaaS平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置(saas平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置)

一、概述

統(tǒng)一身份管理系統(tǒng)(簡稱UIMS)主要關(guān)注4個方面,簡稱4A管理:

  1. 集中賬號管理(Account)
  2. 集中認(rèn)證管理(Authentication)
  3. 集中授權(quán)管理(Authorization)
  4. 集中審計管理(Audit)

可以認(rèn)為是多租戶架構(gòu)的升級版,通常是整個平臺帳號和權(quán)限管控的基礎(chǔ)性系統(tǒng),平臺下所有系統(tǒng)的賬戶管理、身份認(rèn)證、用戶授權(quán)、權(quán)限控制等行為都必須經(jīng)由該系統(tǒng)處理,提供帳號密碼管理、基本資料管理、角色權(quán)限管理等功能。

UIMS 基于『統(tǒng)一身份治理』的概念,可劃分為兩級賬戶體系、基礎(chǔ)權(quán)限模塊和基礎(chǔ)信息模塊三大模塊。

其中兩級賬戶體系將賬戶分為組織實體帳號和個人實體賬戶兩大類,個人實體從屬于組織實體,也可以不從屬任何組織實體,且個人實體可同時從屬于多個組織實體;基礎(chǔ)權(quán)限模塊將各業(yè)務(wù)系統(tǒng)的資源權(quán)限進(jìn)行統(tǒng)一管理和授權(quán);基礎(chǔ)信息模塊用于描述組織實體和個人實體的基本信息,如組織實體名稱、地址、法人,個人實體姓名、電話號碼、性別等基礎(chǔ)信息。UIMS 提供統(tǒng)一的 API 與各子系統(tǒng)連接。

從整個平臺的角度來看,UIMS 除了提供上述功能和服務(wù),還應(yīng)該滿足以下需求:

SaaS平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置(saas平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置)

因此,從功能的角度可以將UIMS 劃分為以下模塊:

1. 功能

1. 系統(tǒng)設(shè)置System Configuration

2. 系統(tǒng)標(biāo)識管理System Identifiers Management

3. 服務(wù)賬戶管理Service Accounts Management

4. 賬戶實體管理Account Entities Management

5. 組織實體管理Organization Entities Management

6. 組織架構(gòu)管理Organization Management

7. 個體賬戶管理Individual Accounts Management

8. 賬戶權(quán)限管理Account Permissions Management

9. 用戶組管理User Group Management

10. 角色管理User Roles Management

11. 資源權(quán)限管理Permission Resources Management

12. 權(quán)限策略組管理Permission Group Management

13. 認(rèn)證審核管理Authentication Management

14. 個人認(rèn)證管理Individual Authentication Management

15. 組織認(rèn)證管理Organization Authentication Management

16. 資質(zhì)審核管理Qualification Management

17. 付費授權(quán)管理Authorization Management

18. 組織授權(quán)管理Organization Authorization Management

2. 頁面

1. 統(tǒng)一注冊頁面Unified Signup Page

2. 統(tǒng)一登錄頁面Unified Signin Page

3. 組織入駐頁面Organization Signup Page

4. 個人實名認(rèn)證頁面Individual Authentication Page

5. 組織實名認(rèn)證頁面Organization Authentication Page

3. API

1. 鑒權(quán)相關(guān)的API

2. 業(yè)務(wù)相關(guān)的API

其中組織綁定和解綁的功能,可以放到『組織實體管理』或『個體賬戶管理』的功能中。需要注意的是,組織綁定與解綁功能,是否與業(yè)務(wù)系統(tǒng)關(guān)聯(lián),下文將進(jìn)行闡述。

二、兩級賬戶體系和基礎(chǔ)權(quán)限模塊

基于『統(tǒng)一身份治理』的理念,采用兩級賬戶體系(UIMS 提供接口)實現(xiàn)多系統(tǒng)融合的平臺級 SAAS。兩級賬戶體系將賬戶類別分為組織實體和個人實體兩類(詳見下文用戶分類)。

個人實體可以從屬于組織實體(可以從屬于多個組織實體),也可以不從屬。個人賬戶體系和組織賬戶體系在云平臺內(nèi)享有的權(quán)限是不一樣的,雖然大部分功能和服務(wù)兩個體系的實體均可獨立使用,互不干擾,但部分功能和服務(wù)有所不同。

1. 原則

1)基本原則

平臺級SAAS 模式賬戶體系應(yīng)遵循以下幾個基本原則:

①個人賬戶統(tǒng)一原則

個人賬戶一次注冊,全平臺通用,類似于全網(wǎng)通行證和SSO,注冊和登錄都在 UIMS 進(jìn)行。

②業(yè)務(wù)權(quán)限獨立原則

每個子系統(tǒng)的權(quán)限體系是獨立管理的?!簜€人賬戶統(tǒng)一原則』明確了賬戶體系是統(tǒng)一的,但是對于每個子系統(tǒng)而言,每個賬戶所能使用的功能和服務(wù),所能查看的數(shù)據(jù)權(quán)限是獨立維護(hù)的,比如XXX 公司(組織)—研發(fā)T3組(組織架構(gòu))—張三(個人)—研發(fā)人員(角色),在 CRM 系統(tǒng)中,擁有的資源權(quán)限(詳見下文),與其在 OA 系統(tǒng)中的所擁有的資源權(quán)限肯定是不一致的。

③組織實體隔離原則

不同的組織實體之間,是相互隔離,獨立管理的。每個組織實體可以自行組織自己的組織架構(gòu)、賬戶體系和權(quán)限體系。不同的組織實體資源權(quán)限也是隔離的。

④從屬關(guān)系隔離原則

個體賬戶與組織實體的從屬關(guān)系是基于單獨的業(yè)務(wù)系統(tǒng)存在的,『個人賬戶統(tǒng)一原則』明確的僅是個人賬戶的全網(wǎng)統(tǒng)一,但組織實體、從屬關(guān)系并沒有統(tǒng)一,并且是隔離的。比如在CRM 系統(tǒng)中,張三(用戶)從屬于 XXXX 公司(組織),但在 OA 系統(tǒng)中,張三(用戶)默認(rèn)是不從屬于任何組織的,從屬關(guān)系受到具體業(yè)務(wù)系統(tǒng)的影響。

事實上,這個原則是非強制的,具體取決于各自的業(yè)務(wù)邏輯和業(yè)務(wù)場景。如果要簡化從屬關(guān)系的管理,那么可以不遵循此原則,即個體賬戶與組織實體的從屬關(guān)系是全平臺統(tǒng)一的,與業(yè)務(wù)系統(tǒng)無關(guān),但這會為降低平臺的靈活性和擴展性。靈活性和復(fù)雜度之間通常要做一個取舍。

2)權(quán)限原則

類似于 RBAC 原則,平臺的權(quán)限體系采用 OS-RBAC 的概念:

1. OS:O 代表 Organization 組織,S 代表 System 業(yè)務(wù)系統(tǒng),即權(quán)限是受到組織實體和業(yè)務(wù)系統(tǒng)雙重影響的。

2. RBAC:基于角色的訪問控制。

3. OS-RBAC:組織實體-業(yè)務(wù)系統(tǒng)-用戶-角色-權(quán)限標(biāo)識。分為兩種情況:一種是有從屬組織的個人賬戶;另一種是無從屬組織的個人賬戶,后者無組織,但同樣遵守 RBAC 的權(quán)限限定,且其權(quán)限標(biāo)識體系允許組織為空。

4. 資源標(biāo)識:分為邏輯資源和實體資源。邏輯資源包括功能資源和數(shù)據(jù)資源,如菜單、頁面、表單、按鈕組、按鈕、字段等功能型資源,或人員檔案、考勤記錄、任務(wù)記錄、位置數(shù)據(jù)、積分、電子錢包等數(shù)據(jù)資源;實體資源如椅子、凳子、電腦、車輛等實物資產(chǎn),另外有時候部分邏輯資源也可以歸納為實體資源,如電子照片、視頻文件、音樂文件等。

5. 條件標(biāo)識:權(quán)限的約束條件,主要有可見組織架構(gòu)范圍限定、時間限定、區(qū)域限定等。例如某權(quán)限僅財務(wù)部可見,有效期至11月2號,這里『財務(wù)部』屬于可見組織架構(gòu)范圍限定,『至11月2號』則是時間限定。

6. 權(quán)限標(biāo)識:用于標(biāo)識賬戶實體在指定的條件下?lián)碛性L問某項功能、查看某些數(shù)據(jù)的權(quán)限。資源標(biāo)識和條件標(biāo)識與權(quán)限標(biāo)識關(guān)聯(lián),權(quán)限標(biāo)識與角色關(guān)聯(lián),角色與用戶關(guān)聯(lián)。例如張三(用戶)-研發(fā)人員(角色)-擁有『研發(fā)部』所有人員檔案的增上改查權(quán)限。

7. 業(yè)務(wù)系統(tǒng)標(biāo)識符:受『業(yè)務(wù)權(quán)限獨立原則』的約束,與傳統(tǒng)的資源權(quán)限有所不同的是,所有權(quán)限標(biāo)識都與具體的業(yè)務(wù)系統(tǒng)關(guān)聯(lián),例如企業(yè)CRM系統(tǒng)就是一個業(yè)務(wù)系統(tǒng),具體的權(quán)限標(biāo)識與業(yè)務(wù)系統(tǒng)有直接的關(guān)系,例如菜單、表單、頁面、按鈕、圖片等資源。

8. 權(quán)限策略組:權(quán)限策略組是在OS-RBAC 基礎(chǔ)上設(shè)置的,為簡化權(quán)限配置的一種輔助手段,在實際應(yīng)用中可以不創(chuàng)建策略組。策略組分為平臺級策略組和業(yè)務(wù)系統(tǒng)級別的策略組,兩種策略組的作用域僅限于相同組織實體內(nèi)部,但對于無從屬組織的個人賬戶除外。策略組與角色類似,可以將資源權(quán)限綁定到策略組中,但不同之處是,平臺級策略組可以橫跨業(yè)務(wù)系統(tǒng)進(jìn)行平臺級的資源權(quán)限綁定。因為賬戶體系跨越多個子系統(tǒng),在遵循『業(yè)務(wù)權(quán)限獨立原則』的限定下,每個子系統(tǒng)都需要做一套權(quán)限配置,操作上較為繁瑣,因此充分運用策略組可以大大簡化權(quán)限配置工作。平臺可以內(nèi)置多套常用的策略組,終端用戶可以直接選用策略組,也可以基于某個策略組為基礎(chǔ),進(jìn)行修改。值得注意的是,策略組的作用域僅限于相同組織實體內(nèi)部,即策略組可以橫跨業(yè)務(wù)系統(tǒng),但不能同時作用于多個組織實體。

9. 權(quán)限交集:與RBAC2 的靜態(tài)職責(zé)分離-角色互斥原則相反,平臺采用多角色權(quán)限并集的設(shè)計。

SaaS平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置(saas平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置)

表1RBAC模型

『權(quán)限標(biāo)識』示例:在企業(yè)CRM系統(tǒng)[1]中,在2019年3月5號以前[2],對百度科技[3],研發(fā)中心[4],在廣東區(qū)域[5]的所有人事檔案[6]擁有只讀權(quán)限[7]。

[1]業(yè)務(wù)系統(tǒng)標(biāo)識;

[2]條件標(biāo)識:時間限定;

[3]組織實體標(biāo)識;

[4]條件標(biāo)識:可見組織架構(gòu)范圍限定;

[5]條件標(biāo)識:區(qū)域范圍限定;

[6]資源標(biāo)識;

[7]權(quán)限類型。

2. 從屬關(guān)系

為簡單起見,我們將不遵守『從屬關(guān)系隔離原則』,即用戶實體與組織實體的從屬關(guān)系與業(yè)務(wù)系統(tǒng)無關(guān)。系統(tǒng)涉及的實體類型有:

1.業(yè)務(wù)系統(tǒng)(系統(tǒng)標(biāo)識)

2.服務(wù)賬戶(客戶端)

3.個人賬戶實體

4.組織賬戶實體

5.組織架構(gòu)

6.用戶組(非必選項)

7.角色實體

8.權(quán)限實體

9.資源實體

10.限定條件實體

11.權(quán)限策略組(非必選項)

1)與組織實體強關(guān)聯(lián)的實體

基于『組織實體隔離原則』,這類實體類型不能脫離組織實體獨立存在。

由于組織架構(gòu)不能脫離組織實體單獨存在,因此當(dāng)用戶實體綁定組織架構(gòu)時,該用戶實體必須隸屬于該組織架構(gòu)所從屬的組織實體。同理可知以下從屬關(guān)系遵從同樣的約束——即每對關(guān)系的兩個實體對象必須屬于相同的組織實體:

2)與業(yè)務(wù)系統(tǒng)強關(guān)聯(lián)的實體

基于『業(yè)務(wù)系統(tǒng)隔離原則』,這類實體類型不能脫離業(yè)務(wù)系統(tǒng)獨立存在。

3. 實體類型

基于以上各項原則,實體類型又分為以下幾種情況:

1)組織實體(未認(rèn)證)

在組織實體的模式下,可以按照組織的管理要求,獨立設(shè)置一套組織架構(gòu)、賬戶和數(shù)據(jù)權(quán)限體系,比如設(shè)置下屬企業(yè)、分公司、部門、崗位職務(wù)、角色權(quán)限,組織實體缺省分配一個管理員帳戶,擁有全部權(quán)限,由管理員初始化配置信息。

2)組織實體(已認(rèn)證)

擁有未認(rèn)證組織實體的所有權(quán)利,但已認(rèn)證的實體通常擁有更多的配額更少的功能限制,此外有些特定的業(yè)務(wù)功能和業(yè)務(wù)流程,必須是實名認(rèn)證的實體才能使用,比如支付和交易。

3)個人實體(未認(rèn)證)

在個人實體的模式下,享受的權(quán)利由具體的業(yè)務(wù)系統(tǒng)決定,原則上個人實體作為獨立的賬戶類型,應(yīng)該享有基本的功能權(quán)限和數(shù)據(jù)權(quán)限,如個人中心的各項功能等。

4)個人實體(已認(rèn)證)

與組織實體(已認(rèn)證)類似。

5)個人實體(未從屬于組織)

未從屬組織的個人實體賬戶,與上述個人實體類型一致。

6)個人實體(從屬單個組織)

從屬單個組織的個人實體賬戶,除了具備個人實體賬戶的原本權(quán)利外,還受到組織權(quán)限的約束,原本個人實體不享受的權(quán)利,可能現(xiàn)在可以享受,原本享受的權(quán)利,可能現(xiàn)在不可以享受了。

7)個人實體(從屬多個組織)

當(dāng)個人實體賬戶從屬于多個組織時,除了個人賬戶原本擁有的權(quán)利外,所從屬的組織所帶來的權(quán)利須遵循『組織實體隔離原則』,且受到『從屬關(guān)系隔離原則』的約束,具體的權(quán)利配置由各個業(yè)務(wù)系統(tǒng)獨立管理。

這里有兩種情況:一是在用戶登錄時,必須選擇所屬的組織機構(gòu),類似于LOL 游戲,在登錄時須選擇所屬的區(qū)域和服務(wù)器;二是在用戶登錄后,可以***選擇組織實體,類似于阿里云華為云的區(qū)域選擇,在用戶未選擇所屬組織時,應(yīng)當(dāng)按照未從屬于組織的個人實體賬戶對待。

8)組織管理員

組織管理員擁有該組織內(nèi)部的全部資源權(quán)限,例如可以創(chuàng)建個人賬戶,在個人未完成首次登錄前,可以刪除(解雇),修改,在個人完成登錄后,則權(quán)限移交給了個人;刪除(解雇)時,只是個人脫離組織,個人不再擁有組織員工的權(quán)限,在組織內(nèi)的個人工作經(jīng)歷仍然保留,組織清除離職員工,則這些在職經(jīng)歷將不為企業(yè)可管理,但個人自己可見,不可變更。

4. 用戶分類

SaaS平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置(saas平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置)

表2用戶分類

5. 組織分類

SaaS平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置(saas平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置)

表3組織分類

三、基礎(chǔ)信息模塊

基礎(chǔ)信息,主要針對個人實體和組織實體,如企業(yè)工商信息、通用信息等要滿足靈活擴展的需求,實體的類型種類繁多,隨著業(yè)務(wù)場景的變化,信息結(jié)構(gòu)的變化也可能比較頻繁。在技術(shù)上建議采用以下兩種方式應(yīng)對:

1. EAV 數(shù)據(jù)模型

EAV 即 Entity(實體)-Attribute(屬性)-Value(值)數(shù)據(jù)模型,將傳統(tǒng)的 ORM 映射模型——即實體屬性與數(shù)據(jù)庫表字段一一對應(yīng)的模型,變換為實體屬性與數(shù)據(jù)表的行記錄一一對應(yīng)的模型。EAV 模型大大增加了數(shù)據(jù)映射和相關(guān)業(yè)務(wù)邏輯的復(fù)雜程度,但是具備高度的靈活性,能夠滿足隨時變化的信息結(jié)構(gòu),滿足動態(tài)變更的實體結(jié)構(gòu)、滿足字段級權(quán)限控制、滿足字段級數(shù)據(jù)版本歷史等功能。

2. 采用松散型數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)庫方案

其中的代表便是MongoDB:一個介于關(guān)系數(shù)據(jù)庫和非關(guān)系數(shù)據(jù)庫之間的分布式文件存儲數(shù)據(jù)庫產(chǎn)品,在 CAP 理論中屬于 CP 范疇,支持松散數(shù)據(jù)結(jié)構(gòu),支持復(fù)雜的混合數(shù)據(jù)類型,支持 JSON 和文檔存儲。采用此方案的優(yōu)勢比較明顯,除了能夠滿足 EAV 模型所具備的大部分功能外,還大大簡化了技術(shù)復(fù)雜度,支持分布式部署,推薦采用此方案。

3. 信息分類

平臺的信息主要分為基礎(chǔ)信息和業(yè)務(wù)信息兩大類?;A(chǔ)信息分為個人實體信息和組織實體信息,主要描述實體的基本信息、通用信息,與業(yè)務(wù)相關(guān)性不大,例如姓名、性別、身份證號碼、手機號碼、企業(yè)通用信息、企業(yè)工商信息等。業(yè)務(wù)信息由各業(yè)務(wù)系統(tǒng)自行管理和維護(hù),UIMS 不涉及。

SaaS平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置(saas平臺下企業(yè)賬號的注冊及認(rèn)證和模型設(shè)置)

所有與信息收集、儲存、處理及數(shù)據(jù)安全有關(guān)的書面政策,應(yīng)當(dāng)出具《隱私政策》并進(jìn)行聲明。部分組織信息由于可在網(wǎng)上公開查到,且是法定必須公布的信息,因此可以默認(rèn)公開。

四、其他功能模塊

1. 軟件授權(quán)

基于兩級賬戶體系,建立云平臺付費授權(quán)機制,針對用戶賬戶和組織賬戶進(jìn)行獨立授權(quán)。根據(jù)產(chǎn)品的商業(yè)策略,可執(zhí)行靈活的付費模式:

  • 時效限制:年付、季付、月付,不同時效費用不同。
  • 功能限制:授權(quán)不同的功能,費用不同。
  • 數(shù)量限制:最大組織數(shù)量限制、最大用戶數(shù)量限制,不同的數(shù)量費用不同。

2. 組織入駐

UIMS 應(yīng)提供一個組織實體注冊登記的流程,允許組織主動提交基本信息,開戶入駐平臺。此外,應(yīng)提供在管理后臺手工錄入組織開戶的功能。

3. 實名認(rèn)證

分為個人賬戶實名認(rèn)證和組織賬戶實名認(rèn)證,盡量通過技術(shù)手段自動執(zhí)行實名認(rèn)證的審核過程,減少甚至取消人工干預(yù)。UIMS 應(yīng)提供實名認(rèn)證的功能和流程。

4. 資質(zhì)審核

資質(zhì)審核分為兩部分:一是部分實體實名認(rèn)證過程中的人工核查;二是對實體提交的額外資質(zhì)進(jìn)行技術(shù)或人工審核。

5. 組織綁定

基于『從屬關(guān)系隔離原則』,個人賬戶應(yīng)在具體的業(yè)務(wù)系統(tǒng)中綁定組織賬戶,綁定過程分為兩種類型:一是由組織管理員手工創(chuàng)建的從屬個人賬戶,另一個是個人賬戶申請加入某個組織。業(yè)務(wù)系統(tǒng)應(yīng)該提供此功能和流程。例如,個人注冊帳號后,可主動登記綁定組織,對已注冊登記的組織則要該組織管理員審核,未在系統(tǒng)中注冊登記的組織,則始終處于待審核狀態(tài)。

6. 組織解綁

允許個人賬戶解除與組織之間的從屬關(guān)系。解綁分為兩種情況:一是個人賬戶主動解除關(guān)系,二是組織管理員解綁、解雇或清除雇員(個人賬戶)。

其中第一種個人解綁的,應(yīng)當(dāng)由組織進(jìn)行審核批準(zhǔn),個人申請解除綁定關(guān)系,組織進(jìn)行審核,但是是否需要審核,應(yīng)交由具體的業(yè)務(wù)系統(tǒng)自行決定。

7. 間接雇傭(從屬)關(guān)系

雇傭(從屬)關(guān)系分為直接雇傭與間接雇傭關(guān)系。例如保安員在某保安公司入職(直接雇傭),在某物業(yè)作保安(間接雇傭)。考慮兩種辦法標(biāo)識間接雇傭關(guān)系。

8. 增加服務(wù)單位(項目點、物業(yè)社區(qū))的實體概念

利用組織內(nèi)部的組織機構(gòu)體系,將間接雇傭單位作為當(dāng)前組織的分支機構(gòu)進(jìn)行處理。

9. 賬戶注銷

分為個人賬戶的注銷和組織賬戶的注銷。UIMS 應(yīng)提供相應(yīng)的頁面完成賬戶注銷的操作。

10. 私有化部署

原則上拒絕私有化部署,但對于特定的客戶,考慮私有化部署。私有化部署須考慮版本升級問題,在軟件架構(gòu)設(shè)計時,盡量遵循業(yè)務(wù)系統(tǒng)和技術(shù)系統(tǒng)分離的原則,并抽離公共模塊,最大限度為私有部署的版本提供升級服務(wù)。

五、總結(jié)

總體來說,統(tǒng)一身份管理系統(tǒng)要做的事情有這么幾件:

1. 定義實體

2. 業(yè)務(wù)系統(tǒng)實體

3. 服務(wù)賬戶實體(客戶端)

4. 組織實體

5. 組織架構(gòu)

6. 個人實體

7. 角色實體

8. 權(quán)限標(biāo)識

9. 資源標(biāo)識

10. 條件標(biāo)識

11. 處理上述各實體之間的關(guān)系,并提供數(shù)據(jù)結(jié)構(gòu)

12. 提供鑒權(quán)API和業(yè)務(wù) API

13. 提供其他功能:統(tǒng)一注冊功能(頁面和流程)、統(tǒng)一登錄功能、軟件授權(quán)、組織入駐、組織綁定/解綁、資質(zhì)審查。

本文由@劉同學(xué) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

版權(quán)聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn),該文觀點僅代表作者本人。本站僅提供信息存儲空間服務(wù),不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容, 請發(fā)送郵件至 舉報,一經(jīng)查實,本站將立刻刪除。

(0)
上一篇 2023年3月29日 下午1:13
下一篇 2023年3月29日 下午1:29

相關(guān)推薦