選擇內容分享方式
本頁面說明開發人員在分享受控內容存取權時，應遵守的最佳做法。您可以在協作活動開始前或進行期間更新權限。
強烈建議您採用可減少使用者摩擦或干擾的做法。開發人員應在應用程式存取控管模型的限制條件、安全性需求和任何使用者中斷情形之間取得平衡。
以下列舉幾種提供協作活動存取權的方式。
授予臨時存取權杖 (建議)
臨時 (到期) 存取權權杖會提供使用者的存取權和安全性憑證，這些憑證在指定時間內有效。詳情請參閱「設定臨時存取權」。
這個方法可減少使用者摩擦。只要有連結和暫時存取權杖，任何人都可以存取內容。使用者只能在權杖中指定的時間範圍內存取資料，權杖會在發起端啟動活動時產生。
您可以使用活動啟動狀態分享權杖。您可以兌換代碼，取得暫時性內容存取權。暫時存取權杖與內容建立時間無關。這項做法適用於新內容和現有內容。
下表列出採用此方法的優缺點：
| 優點 |
缺點 |
| 使用者所需的操作量越少越好 |
分享內容過多 |
| 允許使用者在活動開始後加入 |
|
| 不需要事先瞭解參與者 |
|
在活動開始前分享
另一種做法是設計 Meet 外掛程式，在使用者開始活動前，提示他們更新權限。
下表列出採用此方法的優缺點：
| 優點 |
缺點 |
| 明確共用可將風險降到最低 |
判斷參與者可能很困難 |
|
使用者加入時，需要花費中等程度的時間或中斷服務來核准存取權 |
隨選共用
這是一種反應式方法，活動發起者會在使用者要求存取內容時，即時核准要求。如果無法正確判斷參與者，這個方法可能會造成高使用者摩擦。因此，我們不建議使用這項功能。
下表列出採用此方法的優缺點：
| 優點 |
缺點 |
| 不需要事先瞭解參與者 |
會造成大量干擾，並中斷會議流程 |
| 明確分享可降低風險 |
需要在活動開始後更新內容權限的路徑 |
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2024-12-21 (世界標準時間)。
[null,null,["上次更新時間：2024-12-21 (世界標準時間)。"],[[["Developers should prioritize methods that minimize user friction when sharing access to controlled content during collaborative activities."],["Temporary access tokens are recommended as they provide a balance between security and ease of use, granting temporary access for a specified period."],["Alternative approaches include pre-activity sharing, requiring permission updates before starting, and on-demand sharing, which involves approving access requests in real-time."],["Each approach has advantages and disadvantages, with on-demand sharing potentially causing the most friction due to real-time approvals."],["Developers need to carefully consider security requirements and potential user disruptions when selecting a sharing method."]]],["Developers should balance security and user experience when sharing access to controlled content. The recommended method is granting temporary access tokens, minimizing user friction by providing time-limited access via a shareable link. Alternatively, sharing before the activity starts offers explicit control but can be challenging to manage participants. On-demand sharing, the least recommended, involves real-time approvals and causes high disruption. Permissions can be modified before or during collaborative activities.\n"]]
