【问题标题】:Android SyncAdapter Server-side ImplementationAndroid SyncAdapter 服务器端实现
【发布时间】:2011-12-11 13:50:17
【问题描述】:

我已经阅读了很多关于 Sync Adapter 的教程,例如 http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1 上的教程以及 Android 开发者网站上的 SampleSyncAdapter 示例代码。 但我不明白服务器端如何处理身份验证和同步查询。我可以使用 php 从 mySQL 服务器数据库进行查询吗?

【问题讨论】:

    标签: android mysql synchronization android-syncadapter


    【解决方案1】:

    您缺少的部分不是同步适配器的一部分。这是AbstractAccountAuthenticator。它是实际处理用户密码并将其传递给服务器的类,它需要以与相关服务器完美匹配的方式编写。

    如何:

    首先,这个过程是如何工作的?

    1. 用户在 Settings->Accounts and Sync 页面输入用户名和密码。
    2. (稍后...)同步过程开始。
    3. SyncAdapter 调用blockingGetAuthToken()
    4. AccountAuthenticator 启动。
    5. AccountAuthenticator 使用常规 http(或理想情况下为 https)身份验证连接到服务器,一旦通过身份验证,就会从服务器请求“令牌”。此令牌是一个大的(例如 128 位)随机数,只有在您使用基于密码的身份验证登录时才能从服务器获取。
    6. AccountAutenticator 缓存令牌,然后将令牌返回给 SyncAdapter。
    7. SyncAdapter 尝试访问服务器上的内容,并将令牌作为其请求中 http 标头的一部分传递。
    8. 服务器接受令牌代替普通的 http-auth,并允许服务请求。
    9. 未来的同步尝试最终会跳过这个过程的大部分。在接下来的同步尝试中,当 SyncAdapter 调用 blockingGetAuthToken() 时,AccountAuthenticator 只需返回缓存的令牌,无需重新进行身份验证。

    所以这个令牌是有限使用的——一段时间后,服务器会拒绝接受它。此时,SyncAdapter 尝试使用令牌并收到身份验证错误。那么呢?

    1. SyncAdapter 调用 invalidateToken(token) 并将(现已过期的令牌)传递回 AccountAuthenticator。
    2. AccountAuthenticator 在其缓存中找到令牌并将其丢弃。
    3. 在下一次调用blockingGetAuthToken() 时,AccountAuthenticator 将与服务器通信并获取新令牌。从那里开始,同步正常进行。

    为什么?

    所以有几个优点。

    1. 普通 http 身份验证通过 Internet 以明文形式传输密码。如果使用令牌,则只发送一次密码,多次发送令牌。这在一定程度上减少了密码暴露给嗅探的可能性。
    2. https 身份验证避免了明文问题,但在移动连接方面可能很昂贵。使用令牌可以为实际携带数据的服务器调用提供更轻量级的 http 连接,只有在第一个请求获得令牌时才会看到 https 开销。
    3. 隔离 -- AccountAuthenticator 知道用户的实际密码。 SyncAdapter 只能访问令牌并且永远不会学习密码。这对谷歌来说很重要,因为它允许第三方应用程序使用 gmail 帐户和密码进行身份验证,而无需第三方应用程序(可能是恶意的)获取密码(并将其转发给狡猾的 naer-do -好吧)

    有效期:

    代币有点危险。任何可以访问令牌的人都可以以您的身份登录。所以,这里有好的做法:

    1. 服务器应在固定时间段后使用户的令牌过期。更多的偏执 - 更短的超时。
    2. 只要用户更改密码,服务器就应该使用户的所有令牌过期。
    3. 如果用户在 Web 界面注销。令牌并没有真正的“注销”概念。
    4. 服务器应考虑将令牌绑定到首先请求它的 IP 地址,然后如果不同的 IP 地址随后尝试使用该令牌,则拒绝验证(但不一定会使令牌过期)。如果你这样做,服务器肯定需要能够为每个用户创建多个令牌(每个用户一个令牌:ipaddress 组合)——考虑一个有两个移动设备的用户——否则,每次同步时,它都会失效对方的令牌。还要考虑一下,两台设备都在家庭wifi上(在路由器后面共享一个IP地址,然后一台设备离开并开始使用移动网络——这就是你可能选择不过期的原因,所以仍然坐在家里的设备可以继续使用令牌。但是,漫游的一个设备将看到身份验证失败并建立自己的新令牌。当它回到家时,服务器应确保提供已为该 IP 地址建立的相同令牌。)
    5. 根据您的偏执程度,请考虑仅通过 https 接受身份验证令牌。 Firesheep 是一个很好的例子,说明被盗的 Auth Token 可以获得什么。如果您有用户敏感数据,则应仅通过 https 接受。此外,即使您没有用户敏感数据,您也可以考虑编写一个协议,要求 https 更改数据库,同时允许 http 读取。

    【讨论】:

    • 为什么不能每次都对用户名和密码进行哈希处理并发送?跳过一些对我来说似乎很愚蠢的步骤。
    • 因为任何人只要在散列传输过程中截获并存储散列,就可以像您一样从任何地方永远登录。你用过免费的wifi热点吗?热点的所有者和使用它的每个人都可以看到并记录您传输的每一位。它已在现场得到证明。请参阅codebutler.com/firesheep,了解一个涉及窃取 Facebook 凭据的显着示例。请注意,这甚至会窃取身份验证 cookie。使用 auth cookie,他们会在服务器更新 cookie 时失去访问权限,但使用用户名/密码哈希,他们可以访问,直到您更改密码。
    • 除非你对哈希加盐,这比处理令牌的麻烦要简单得多
    • 盐不是问题,@Mbrevda。如果您将盐、用户名和密码传递到散列中,那么如果您在传输过程中截获该散列,那么您将拥有一个永不改变的散列,与设备或登录时间无关,并且仍然可以从任何地方使用,永远以您的身份进行身份验证。这和丢失密码一样糟糕。
    • 对不起,我的意思是一个随机数。如果您传递一个用户名、一个随机数和一个哈希,那么唯一保持不变的是用户名。哈希和随机数每次都会改变。为防止重放,要么使 nonce 基于时间(以便它现在才起作用),要么跟踪 nonce/hash 的使用情况,并且永远不允许再次使用它们。
    猜你喜欢
    • 2018-05-19
    • 2017-07-09
    • 1970-01-01
    • 1970-01-01
    • 2017-05-29
    • 2013-07-21
    • 2013-04-11
    • 2012-11-15
    • 2019-03-22
    相关资源
    最近更新 更多