安全

隨著應用程序開發(fā)的進行，您將需要使用Parse的安全功能來保護數(shù)據(jù)辩恼。本文檔介紹了如何保護應用程序雇庙。

如果您的應用遭到破壞，那么遭受損失的不僅僅是作為開發(fā)人員的你灶伊，還有應用的用戶疆前。在您的應用程序發(fā)布之前，請繼續(xù)閱讀我們在默認值和預防措施上的合理建議聘萨。

客戶端 vs. 服務器

當應用程序首次連接到Parse時竹椒，它會使用ApplicationID和客戶端密鑰（REST Key、.NET Key或JavaScript Key米辐，具體取決于您使用的平臺）來確認自己的身份胸完。這些并不是加密的，而且不能用來保護應用程序翘贮。這些密鑰是作為您應用程序的一部分發(fā)送的赊窥，任何人都可以通過反編譯您的應用或代理網絡流量查找到您的客戶端密鑰。這個漏洞甚至更容易利用JavaScript發(fā)現(xiàn) —— 只需在瀏覽器中“查看源代碼”即可找到客戶端密鑰择膝。

這就是為什么Parse有許多其他安全機制來幫助您保護數(shù)據(jù)誓琼〖旒ぃ客戶端密鑰已經交給了您的用戶肴捉，所以僅通過客戶端密鑰可以完成的操作都可以由一般公眾、甚至惡意黑客實現(xiàn)叔收。

另一方面齿穗，主密鑰（Master Key）絕對是一種安全機制。使用主密鑰可以繞應用程序的過所有安全機制饺律，例如類級權限和ACL窃页。有了主密鑰就像擁有應用程序服務器的root權限，因此要像保護生產計算機的root密碼一樣來保護您的主密鑰。

總體原則是限制客戶端的權限（使用客戶端密鑰）脖卖，在Cloud Code中執(zhí)行任何敏感操作時應使用主密鑰乒省。您將在“在Cloud Code中實現(xiàn)業(yè)務邏輯”一節(jié)中學習如何最大限度地利用此功能。

最后一個注意事項：建議您在服務器中設置HTTPS和SSL畦木，以避免中間人攻擊袖扛，但是Parse在非HTTPS連接中也很好用。

1.Class-level權限

第二級的安全性在Schema和數(shù)據(jù)級別十籍。執(zhí)行此級別的安全措施將限制客戶端應用程序如何以及何時在Parse中訪問和創(chuàng)建數(shù)據(jù)蛆封。當您第一次開始開發(fā)Parse應用程序時，所有默認設置都已設置好為使您開發(fā)起來更高效勾栗。例如：

• 客戶端應用程序可以在Parse上創(chuàng)建新的類
• 客戶端應用程序可以向類添加字段
• 客戶端應用程序可以修改或查詢Parse上的對象

您可以將任何這些權限應用到所有人惨篱、無人能用、或應用于您應用中的特定用戶或角色围俘。角色是包含用戶或其他角色的組砸讳，您可以將其分配給對象以限制其使用。授予角色的任何權限也被授予其任何子級——無論他們是用戶還是其他角色楷拳，都可以在應用上創(chuàng)建訪問層級绣夺。Parse指南中包含了在應用程序中使用角色的詳細說明称簿。

一旦您確信您的應用程序中的類之間具有正確的類和關系黎棠，您就應該通過以下操作來將其鎖定：

幾乎每個你創(chuàng)建的類都應該在某種程度上調整這些權限酿傍。對于類中的每個對象具有相同權限的碉输，類級別權限設置將是最高效的配紫。例如饲漾，一個常見的用例是一個靜態(tài)數(shù)據(jù)的類先匪，任何人都可以讀取捎拯，而沒有任何人可寫坤按。

1.限制Class的創(chuàng)建

首先毯欣，您在應用程序中配置客戶端不能在Parse上創(chuàng)建新類〕襞В可以通過在Parse Server配置中設置鍵allowClientClassCreation為false來完成酗钞。有關配置Parse Server的概述，請參閱自述文件来累。一旦設置此限制砚作，類只能通過數(shù)據(jù)瀏覽器或masterKey創(chuàng)建。這樣可以防止攻擊者用無限制的隨機新類填充數(shù)據(jù)庫嘹锁。

2.配置Class-level權限

Parse中葫录，您可以指定每個類允許的操作。這可以限制客戶端訪問或修改類的方式领猾。要更改這些設置米同，請轉到數(shù)據(jù)瀏覽器骇扇，選擇一個類，然后單擊“安全”按鈕面粮。

您可以配置客戶端對所選類執(zhí)行以下每個操作的能力：

• 讀：

• • Get：使用Get權限少孝，如果用戶知道他們的objectIds，用戶就可以在該表中獲取對象熬苍。
• • Find：具有Find權限的任何人都可以查詢表中的所有對象韭山，即使他們不知道他們的objectIds。具有public Find權限的任何表都將被公眾完全可讀冷溃，除非您在每個對象上設置其ACL钱磅。

• 寫：

• • Update：具有Update權限的任何人都可以修改表中沒有設置ACL的任何對象的字段。對于公開可讀的數(shù)據(jù)似枕，如游戲級別或資產盖淡，您應該禁用此權限。
• • Create：與Update類似凿歼，具有Create權限的任何人都可以在類中創(chuàng)建新的對象褪迟。與Update權限一樣，對于公開可讀的數(shù)據(jù)答憔，您應該關閉此權限味赃。
• • Delete：通過此權限，你可以刪除表中沒有設置ACL的任何對象——只需要知道它的objectId虐拓。

• Add fields：對象被創(chuàng)建時心俗，Parse類會推定其模式。在開發(fā)應用程序時蓉驹，這是非常好的城榛，因為您可以向對象添加一個新的字段，而不必對后端進行任何更改态兴。但是狠持，一旦你發(fā)布了應用程序，就很少需要自動在類中添加新的字段瞻润。因此喘垂，當您發(fā)布應用程序后，應該幾乎總是關閉所有類的此權限绍撞。

對于上述每個操作正勒，您都可以向所有用戶（默認值）授予權限，也可以將權限鎖定到一組角色和用戶列表楚午。例如昭齐，所有用戶都可以使用的類可通過僅啟用get和find來設置為只讀尿招，可通過僅允許create將logging類設置為只寫矾柜。您可以在特定的一組用戶或角色上設置update和delete權限來啟用用戶內容的審核功能阱驾。

2.Object-Level訪問控制

前面您鎖定了Schema和類級別的權限，現(xiàn)在就該考慮用戶如何訪問數(shù)據(jù)了怪蔑。Object-Level訪問控制使一個用戶的數(shù)據(jù)與另一個用戶的數(shù)據(jù)保持分離里覆，因為有時候類中不同的對象只能被不同的人訪問。例如缆瓣，用戶的私有個人數(shù)據(jù)只能由他們自己訪問喧枷。

Parse還支持應用程序中的匿名用戶存儲和保護其特定數(shù)據(jù)而不需要顯式登錄。

當用戶登錄到應用程序時弓坞，它們會啟動與Parse的會話隧甚。通過這個會話，他們可以添加和修改自己的數(shù)據(jù)渡冻，但阻止其修改其他用戶的數(shù)據(jù)戚扳。

1.訪問控制表（ACCESS CONTROL LISTS）

控制誰可以訪問哪些數(shù)據(jù)最簡單的方法就是通過訪問控制列表（通常稱為ACL）。ACL背后的思想是每個對象都有一組用戶和角色的列表族吻，以及用戶或角色具有的權限帽借。用戶需要有讀取權限（或必須屬于具有讀取權限的角色）才能檢索一個對象的數(shù)據(jù)，同時用戶需要寫入權限（或必須屬于具有寫入權限的角色）才能更新或刪除該對象超歌。

擁有用戶后砍艾，您可以開始使用ACL。記孜【佟：用戶可通過傳統(tǒng)的用戶名/密碼注冊脆荷、Facebook或Twitter等第三方登錄系統(tǒng)、甚至使用Parse的自動匿名用戶功能創(chuàng)建懊悯。要將當前用戶的數(shù)據(jù)ACL設置為不公開可讀简烘，您只需要執(zhí)行以下操作：

var user = Parse.User.current();
user.setACL(new Parse.ACL(user));

大多數(shù)應用程序應該這樣做。如果您存儲任何敏感的用戶數(shù)據(jù)（如電子郵件地址或電話號碼）定枷，則需要設置這樣的ACL孤澎，使得用戶的私人信息對其他用戶不可見。如果對象沒有ACL欠窒，那么每個人都可以讀寫覆旭。唯一的例外是_User類。我們絕不允許用戶寫其他用戶的數(shù)據(jù)岖妄，但默認情況下可以讀取型将。（如果作為開發(fā)者你需要更新其他_User對象，請記住荐虐，您的主密鑰就可以提供此功能）七兜。

為了使每個對象都非常容易創(chuàng)建用戶私有的ACL，我們可以設置一個默認的ACL福扬，該ACL將用于您創(chuàng)建的每個新對象：

// not available in the JavaScript SDK

如果您希望用戶同時擁有一些公開的數(shù)據(jù)和一些私有的數(shù)據(jù)腕铸，則最好有兩個單獨的對象惜犀。您可以在公共數(shù)據(jù)中添加一個指向私有數(shù)據(jù)的指針。

var privateData = Parse.Object.extend("PrivateUserData");
privateData.setACL(new Parse.ACL(Parse.User.current()));
privateData.set("phoneNumber", "555-5309");

Parse.User.current().set("privateData", privateData);

當然狠裹，您可以對對象設置不同的讀寫權限虽界。例如，以下是如何為用戶的公共帖子創(chuàng)建一個任何人都可以讀取的ACL：

var acl = new Parse.ACL();
acl.setPublicReadAccess(true);
acl.setWriteAccess(Parse.User.current().id, true);

有時候涛菠，基于每個用戶來管理權限不太方便莉御，于是您希望使用具有同等權限的用戶組（例如一組具有特殊權限的管理員）來實現(xiàn)。角色是一種特殊的對象俗冻，它讓您可以創(chuàng)建能分配給ACL的一組用戶礁叔。角色最棒的是，您可以從角色中添加和刪除用戶迄薄，而無需更新限制為該角色訪問的每個對象晴圾。要創(chuàng)建只能由管理員才能寫入的對象：

var acl = new Parse.ACL();
acl.setPublicReadAccess(true);
acl.setRoleWriteAccess("admins", true);

當然，這段代碼假定你已經創(chuàng)建了一個名為“admins”的角色噪奄。當開發(fā)應用程序時死姚，預先設置一小組特殊角色通常也是合理的。角色也可以即時創(chuàng)建和更新——例如勤篮，在每個連接已經建立后都毒，還是可以將新朋友添加到“friendOf___”角色。

這一切只是一個開始碰缔。應用程序可以通過ACL和類級權限來強制執(zhí)行各種復雜的訪問模式账劲。例如：

• 對于私有數(shù)據(jù)，只有所有者可以讀取和寫入金抡。
• 對于留言板上的帖子瀑焦，作者和“版主”角色的成員具有“寫入”權限，一般公眾具有“讀取”權限梗肝。
• 對于日志數(shù)據(jù)榛瓮，僅能由開發(fā)人員通過使用主密鑰的REST API訪問，而ACL拒絕所有權限巫击。
• 由特權用戶組或開發(fā)人員創(chuàng)建的數(shù)據(jù)禀晓，如當天的全局消息，可以具有公共讀取權限坝锰，但限制只有“管理員”角色有寫入權限粹懒。
• 從一個用戶發(fā)送到另一個用戶的消息，只有這些用戶擁有“讀取”和“寫入”權限顷级。

舉個例子凫乖，以下ACL的形式，它限制為僅所有者（由其objectId標識"aSaMpLeUsErId"）有讀取和寫入權限、其他用戶只能讀取該對象：

{
    "*": { "read":true },
    "aSaMpLeUsErId": { "read" :true, "write": true }
}

以下是使用角色設置ACL形式的另一個示例：

{
    "role:RoleName": { "read": true },
    "aSaMpLeUsErId": { "read": true, "write": true }
}

2.指針權限

指針權限是一種特殊類型的類級權限帽芽，基于用戶存儲在這些對象的指針字段删掀，它可以為類中的每個對象創(chuàng)建一個虛擬ACL。例如嚣镜，給定一個帶有owner字段的類，為owner字段設置讀取指針權限橘蜜，將使該類中的每個對象只能被該對象owner字段中的用戶所讀取菊匿。對于具有一個sender和一個reciever字段的類，receiver字段的讀取指針權限和sender字段的讀寫指針權限计福，會使類中的每個對象讓sender和receiver字段的用戶可讀跌捆，同時僅能讓sender字段的用戶可寫。

鑒于對象通常已經有了指針象颖，它指向對該對象有權限的用戶佩厚，因此指針權限提供了一個簡單而快速的解決方案，以便使用已經存在的數(shù)據(jù)保護您的應用程序说订，而不需要編寫任何客戶端代碼或Cloud Code抄瓦。

指針權限就像虛擬ACL。它們不會出現(xiàn)在ACL列中陶冷，如果您熟悉ACL的工作原理钙姊，您可以將其視為ACL。在上面sender和receiver的例子中埂伦，每個對象就相當于具有一個如下的ACL：

{
    "<SENDER_USER_ID>": {
        "read": true,
        "write": true
    },
    "<RECEIVER_USER_ID>": {
        "read": true
    }
}

請注意煞额，這個ACL上并不是實際的在每個對象上創(chuàng)建。當您添加或刪除指針權限時沾谜，任何現(xiàn)有的ACL都不會被修改膊毁，并且如果由指針權限創(chuàng)建的虛擬ACL和對象上已有的實際ACL同時允許，任何嘗試與對象交互的用戶只能與該對象交互基跑。因此婚温，有時可能會混淆指針權限和ACL，因此我們建議對沒有設置很多ACL的類使用指針權限媳否。幸運的是缭召，當您以后決定使用Cloud Code或ACL來保護應用程序，刪掉指針權限也很容易逆日。

3.需要驗證權限（需要PARSE-SERVER > = 2.3.0）

從2.3.0版本開始嵌巷，parse-server引入了一個新的類級別權限requiresAuthentication。此CLP可防止任何未經身份驗證的用戶執(zhí)行CLP保護的操作室抽。

例如搪哪，你想要讓經身份驗證的用戶，可從你的應用程序中find和get Announcement坪圾，而管理員角色擁有所有特權晓折，可以這樣設置CLP：

// POST http://my-parse-server.com/schemas/Announcement
// Set the X-Parse-Application-Id and X-Parse-Master-Key header
// body:
{
  classLevelPermissions:
  {
    "find": {
      "requiresAuthentication": true,
      "role:admin": true
    },
    "get": {
      "requiresAuthentication": true,
      "role:admin": true
    },
    "create": { "role:admin": true },
    "update": { "role:admin": true },
    "delete": { "role:admin": true },
  }
}

以上設置的效果：

• 非驗證用戶將無法做任何事情惑朦。
• 經過身份驗證的用戶（具有有效sessionToken的用戶）將能夠讀取該類中的所有對象
• 屬于admin角色的用戶能夠執(zhí)行所有操作漓概。

警告：請注意漾月，這樣做絕對不能保護您的內容，如果允許任何人登錄到您的服務器梁肿，那么每個客戶端仍然可以查詢此對象吩蔑。

4.CLP和ACL交互

類級別權限（CLP）和訪問控制列表（ACL）是保護應用程序的強大工具飒责，但它們并不總是完全按您期望的方式進行交互赘娄。它們實際上表示每個請求必須通過兩個獨立的安全層擅憔，以返回正確的信息或進行預期的更改。這些層檐晕，一個在類級別暑诸，一個在對象級別，如下所示辟灰。請求必須通過這兩個層的檢查才能被授權个榕。請注意，盡管行為類似于ACL芥喇，指針權限仍然是類級別許可的一種類型西采，因此請求必須通過指針權限檢查才能通過CLP檢查。

clp_vs_acl_diagram.png

您可以看到继控，當您同時使用CLP和ACL時械馆，用戶是否有權提出一個請求可能會變得復雜。讓我們通過一個例子來更好地了解CLP和ACL如何交互武通。假設我們有一個Photo類霹崎，它有一個對象photoObject；應用程序中有2個用戶冶忱，user1和user2尾菇。我們在Photo類上設置一個Get CLP ，禁用public Get，但允許user1執(zhí)行Get派诬。同時劳淆，我們還在photoObject上設置一個ACL，只允許user2讀權限（包括GET）默赂。

您可能期望這將允許user1和user2都能Get photoObject沛鸵，但是因為CLP層的認證和ACL層都會在任何時候起效，它實際上也使得user1也user2都不能獲取photoObject缆八。如果user1嘗試Get photoObject曲掰，它將通過CLP層驗證，但是會因通不過ACL層而被拒絕耀里。同樣的蜈缤，如果user2嘗試Get photoObject拾氓，它將在CLP層驗證就被拒絕冯挎。

現(xiàn)在再看看使用指針權限的示例。假設我們有一個Post類咙鞍，它有一個對象myPost房官。應用程序中有2個用戶，poster和viewer续滋。假設我們添加一個指針權限翰守，它允許任何人在Post類的Creator字段有讀取和寫入權限，而對于myPost對象疲酌，poster是Creator字段的用戶蜡峰。對象上還有一個ACL，給予viewer讀取權限朗恳。您可能期望這將允許poster讀取和編輯myPost湿颅，同時viewer可讀取它，但viewer將被指針權限拒絕粥诫，同時poster將被ACL拒絕油航，因此同樣，兩個用戶都無法訪問該對象怀浆。

由于CLP谊囚、指針權限和ACL之間的復雜交互，我們建議在一起使用時要小心执赡。通常镰踏，僅使用CLP來禁用特定請求類型的所有權限，然后再對其他請求類型使用指針權限或ACL是很有用的沙合。例如余境，您可能需要禁用Photo類的“刪除” ，然后再在Photo上設置指針權限，使得創(chuàng)建它的用戶可以對其進行編輯芳来，但不能刪除它含末。由于指針權限和ACL相互作用特別復雜，我們通常建議僅使用這兩種安全機制中的一個即舌。

5.安全邊界案例

Parse中有一些特殊的類不遵循與其他類相同的安全規(guī)則佣盒。并不是所有的類都遵循類級別權限（CLP）或訪問控制列表（ACL）定義的規(guī)則，以下就是一些例外顽聂。這里的“正常行為”是指CLP和ACL正常工作時肥惭，而腳注中則是其他特殊行為。

• [1] 登錄或REST API中的/1/login牵囤，在User類上不遵守Get CLP。登錄僅基于用戶名和密碼滞伟，不能使用CLP進行禁用揭鳞。

• [2] 檢索當前用戶或基于會話令牌（session token）的用戶，都存在于REST API中的/1/users/me梆奈，在User類上不遵守Get CLP野崇。

• [3] Read ACL不適用于登錄用戶。例如亩钟，即使所有用戶對象都具有禁用讀取的ACL乓梨，對用戶執(zhí)行find查詢仍將返回登錄用戶。但是清酥，如果Find CLP被禁用扶镀，嘗試對用戶執(zhí)行Find還是會返回錯誤。

• [4] 創(chuàng)建CLP也適用于注冊总处。因此狈惫，在User類中禁用Create CLP也會禁止用戶在沒有主密鑰的情況下注冊。

• [5] 用戶只能更新和刪除自己鹦马。公共CLP的更新和刪除可能仍然適用胧谈。例如，如果在User類禁用公共更新荸频，則用戶無法編輯自己菱肖。但是，無論在用戶對象的ACL寫入什么旭从，該用戶仍然可以更新或刪除自己稳强，同時其他用戶都不能更新或刪除該用戶场仲。然而，一如以往退疫，使用主密鑰用戶可以更新其他用戶渠缕，而不受CLP或ACL的影響。

• [6] Installation上的Get請求正常遵循ACL褒繁。除非提供installationId作為約束亦鳞，否則不允許沒有主密鑰執(zhí)行Find請求。

• [7] Installation上的Update請求完全遵守其上定義的ACL棒坏，但Delete請求僅限于主密鑰燕差。有關Installation如何工作的更多信息，請查看REST指南的installations部分坝冕。

3.Cloud Code中的數(shù)據(jù)完整性

對于大多數(shù)應用程序徒探，僅關注密鑰、類級別權限和對象級別ACL喂窟，就能保持應用程序和用戶數(shù)據(jù)的安全测暗。但有時候，對某些邊緣案例谎替，僅有他們還不夠偷溺。對于這些情況蹋辅，還好我們有“Cloud Code”钱贯。

Cloud Code允許您將JavaScript上傳到Parse Server，服務器將為您運行侦另。與在用戶設備上運行客戶端代碼可能被篡改不同秩命，“Cloud Code”保證運行您編寫的代碼，因此更加值得信賴褒傅。

Cloud Code的一個特別常見的用例是防止存儲無效數(shù)據(jù)弃锐。對于這種情況，特別重要的一點是客戶端惡意代碼無法繞過驗證邏輯殿托。

要創(chuàng)建驗證（validation）功能霹菊，Cloud Code允許在類上實現(xiàn)一個beforeSave觸發(fā)器。每當保存對象時支竹，都會運行這些觸發(fā)器旋廷，并允許您修改該對象或完全拒絕保存操作。例如礼搁，以下創(chuàng)建了一個Cloud Code beforeSave觸發(fā)器饶碘，以確保每個用戶都設置了一個電子郵件地址：

Parse.Cloud.beforeSave(Parse.User, function(request, response) {
  var user = request.object;
  if (!user.get("email")) {
    response.error("Every user must have an email address.");
  } else {
    response.success();
  }
});

驗證可以鎖定您的應用程序，以便只接受某些特定值馒吴。您還可以使用afterSave驗證來規(guī)范化您的數(shù)據(jù)（例如扎运，格式化所有電話號碼或統(tǒng)一貨幣）瑟曲。您可以保留直接從客戶端應用程序中訪問Parse數(shù)據(jù)的大部分優(yōu)勢，但同時也可以即時強制規(guī)范數(shù)據(jù)的特定形式豪治。

需要驗證的常見場景包括：

• 確保電話號碼的格式正確
• 凈化數(shù)據(jù)洞拨，使其形式歸一化
• 確保電子郵件地址看起來像一個真正的電子郵件地址
• 要求每個用戶指定特定范圍內的年齡
• 不讓用戶直接更改計算字段
• 不允許用戶刪除特定對象，除非滿足某些條件

4.在Cloud Code中實現(xiàn)業(yè)務邏輯

雖然驗證在Cloud Code中通常是有意義的负拟，但是可能某些操作特別敏感扣甲，應盡可能小心保護。在這種情況下齿椅，您可以完全移除客戶端的權限或邏輯琉挖，而是將所有這些操作轉移到Cloud Code Function中。

當調用Cloud Code Function時涣脚，可以使用可選參數(shù){useMasterKey:true}來獲得修改用戶數(shù)據(jù)的權限示辈。使用主密鑰，您的Cloud Code Function可以覆蓋任何ACL并寫入數(shù)據(jù)遣蚀。這意味著它將繞過您在前幾節(jié)中所設置的所有安全機制矾麻。

假設你想允許用戶“l(fā)ike”一個Post對象，而不給他們對該對象的完全寫入權限芭梯。您可以通過讓客戶端調用Cloud Code Function而不是修改Post本身來完成此操作：

應該小心地使用主密鑰险耀。僅在單次API函數(shù)調用需要覆寫其安全機制時，才設置useMasterKey為true：

Parse.Cloud.define("like", function(request, response) {
  var post = new Parse.Object("Post");
  post.id = request.params.postId;
  post.increment("likes");
  post.save(null, { useMasterKey: true }).then(function() {
    // If I choose to do something else here, it won't be using
    // the master key and I'll be subject to ordinary security measures.
    response.success();
  }, function(error) {
    response.error(error);
  });
});

Cloud Code的一個非常常見的用例是向特定用戶發(fā)送推送通知玖喘。一般來說甩牺，不能信任由客戶端直接發(fā)送推送通知，因為他們能修改提示信息累奈，或推送信息到不該推送的用戶贬派。您可以在應用程序設置中設定是否啟用“客戶端推送”; 我們建議您確保它已被禁用。相反澎媒，您應該編寫Cloud Code Function搞乏，以在推送前驗證一下即將推送并發(fā)出的數(shù)據(jù)。

5.Parse安全性總結

Parse提供了許多方法來保護您應用程序中的數(shù)據(jù)戒努。當您構建應用程序并評估將要存儲的數(shù)據(jù)種類時请敦，可以決定選擇何種實現(xiàn)方式。

值得重申的是储玫，默認情況下侍筛，所有其他用戶都可以讀取Parse User對象。如果您希望防止User對象中的數(shù)據(jù)（例如缘缚，用戶的電子郵件地址）被其他用戶可見勾笆，您需要相應地在User對象上設置ACL。

您應用程序中大多數(shù)的類都將屬于幾種易于保障安全的類別桥滨。對于完全公開的數(shù)據(jù)窝爪，您可以使用類級別的權限來鎖定表弛车，以便公開可讀但無人可寫。對于完全私有數(shù)據(jù)蒲每，您可以使用ACL來確保只有擁有數(shù)據(jù)的用戶可以讀取它纷跛。但偶爾您會遇到不希望數(shù)據(jù)完全公開或完全私有的情況。例如邀杏，有一個社交應用贫奠，您擁有的用戶數(shù)據(jù)應該只有他們已經批準的朋友才能讀取。為此望蜡，您需要結合本指南中討論的技術唤崭，才能實現(xiàn)所需的共享規(guī)則。

我們希望您可以盡可能地使用這些工具保護您應用數(shù)據(jù)和用戶數(shù)據(jù)的安全脖律。讓我們一起構建一個更安全的互聯(lián)網谢肾。