【问题标题】:Is PropertiesService in Google Apps Script secure?Google Apps 脚本中的 PropertiesService 是否安全?
【发布时间】:2018-02-14 08:42:33
【问题描述】:

在一个谷歌应用程序脚本项目中,我需要存储一些敏感用户的数据以供以后执行。假设在第一次执行期间,用户提供了一些数据,而第二次脚本使用了这些数据。

有很多方法可以做到这一点,比如保存在一些谷歌文档中或将其保存到驱动器中。但是,我认为最干净的方式是将其存储在 PropertiesService.getUserProperties()

它工作得很好,但是我不确定这种方法是否足够安全。目前尚不清楚这些数据是如何存储的。我找不到任何技术说明。我浏览了cookies,看起来它不使用cookies。也许,它存储在 G 服务器上的某个地方,但是其他一些脚本能够读取我放入 UserProperties 中的数据吗?此外,目前尚不清楚设置属性的生命周期是多少,它们是否可以永久存在,直到某些脚本将其删除?

更新

Going GAS 书中有关属性服务的一章中,我发现了一些有趣的注释

当 Apps 脚本首次启动时,特定用户可以访问 UserProperties,而不是绑定到特定脚本。 如今,每个脚本都有自己的 UserProperties 类,只能由特定的脚本从该脚本中访问 用户。

这意味着 user1 下的 script1 存储在 UserProperties 中的任何数据都不能在 user1script2 中访问/em>。我实际上进行了快速测试以确认这一点。

另一个注释

Apps Script Properties 服务位于云端,因此不依赖于任何 特定的机器、环境或操作系统。

这部分证实了我的假设,即属性存储在运行 *.gs 脚本的 G 服务器上。

考虑到这一点,我会说使用 Properties Service 在某种程度上是可靠和安全的。

很高兴听到任何关于此的 cmets。

【问题讨论】:

    标签: google-apps-script


    【解决方案1】:

    取决于您的范围。

    • 它可以作用于一个脚本:

      var scriptProperties = PropertiesService.getScriptProperties();
      scriptProperties.setProperty('SERVER_URL', 'http://www.example.com/');
      
    • 脚本的一个用户

      var userProperties = PropertiesService.getUserProperties();
      userProperties.setProperty('DISPLAY_UNITS', 'metric');
      
    • 或一份文件

      var documentProperties = PropertiesService.getDocumentProperties();
      documentProperties.setProperty('SOURCE_DATA_ID', '1234567890abcdefghijklmnopqrstuvwxyz');
      

    这是访问表,from the docs

    +--------------------+---------------------------------------------------------------------------------------------------+-------------------------------------------------------+-------------------------------------------------------------------+
    |                    |                                         Script Properties                                         |                    User Properties                    |                        Document Properties                        |
    +--------------------+---------------------------------------------------------------------------------------------------+-------------------------------------------------------+-------------------------------------------------------------------+
    | Method to access   | getScriptProperties()                                                                             | getUserProperties()                                   | getDocumentProperties()                                           |
    | Data shared among  | All users of a script, add-on, or web app                                                         | The current user of a script, add-on, or web app      | All users of an add-on in the open document                       |
    | Typically used for | App-wide configuration data, like the username and password for the developer's external database | User-specific settings, like metric or imperial units | Document-specific data, like the source URL for an embedded chart |
    +--------------------+---------------------------------------------------------------------------------------------------+-------------------------------------------------------+-------------------------------------------------------------------+
    

    没有明确的迹象表明属性的寿命是多少或它们存储在哪里,但从quotas doc,我们知道:

    • 店铺与消费者账号绑定
    • 每个值最多可以存储 9kb,每个属性存储最多可以存储 500kb。 (ofc 如果您付款,您可以延长这些限制)
    • 所有限制都可能随时取消、减少或更改,恕不另行通知。

    【讨论】:

    • 感谢@Adelin 在我的情况下,我需要使用 UserProperties,因为它是用户的特定数据,并且脚本可以跨多个文档运行。您的回答迫使我再次阅读 G 文档,我注意到 getUserProperties() - 获取只有 当前用户可以访问并且只能在此脚本中访问的属性存储。因此,看起来 getUserProperties() 将为每个用户和每个脚本返回一个商店。这意味着另一个脚本将无法读取我的脚本设置的用户道具。但是,目前还不清楚这些道具存放在哪里以及它们的寿命是多少?
    • @blisss05 我在答案中添加了更新 - 但我认为这是我能给出的最多的,因为确实不是很清楚限制是什么或其他类似的细节
    • 感谢您的回答。了解 PropertyService 的基线会很有帮助。我找到了一些有关它的信息,请参阅我的问题中的更新。我相信在这一点上我只有一个不清楚的问题。房产的寿命是多久?他们有时间吗?我会继续寻找。
    • @blisss05 from this line 所有限制都可能随时取消、减少或更改,恕不另行通知。 我明白,如果他们愿意,他们可以减少明天限制为0,瞬间删除属性。那么属性的寿命有多长?无限期
    • 无限期 :) 我相信这可能是一个正确的答案。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-12-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-10-30
    相关资源
    最近更新 更多