Android SyncAdapter服务器端实现

Dar*_*ara 2 mysql android synchronization android-syncadapter

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

jcw*_*ger 15

您丢失的部分不是同步适配器的一部分.就是这样AbstractAccountAuthenticator.这是实际处理用户密码并将其传递给服务器的类,它需要以与所讨论的服务器配对良好的方式编写.

怎么样:

首先,这个过程如何运作?

  1. 用户在"设置" - >"帐户和同步"页面上输入用户名和密码.
  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(令牌)并将(现在已过期的令牌)传递回AccountAuthenticator.
  2. AccountAuthenticator在其缓存中找到令牌并将其丢弃.
  3. 在下次调用blockingGetAuthToken()时,AccountAuthenticator将与服务器通信并获取新令牌.从那里,同步正常进行.

为什么?

所以有几个优点.

  1. 普通的http auth通过互联网以明文形式传输密码.如果使用令牌,则密码仅发送一次,令牌多次.这有点减少了嗅探密码的暴露.
  2. https身份验证避免了明文问题,但就移动连接而言可能很昂贵.令牌的使用允许实际承载数据的服务器调用的轻量级http连接,仅在获得令牌时在第一个请求上看到https开销.
  3. 隔离 - AccountAuthenticator知道用户的实际密码.SyncAdapter只能访问令牌,从不学习密码.这对Google来说非常重要,因为它允许第三方应用使用gmail帐户和密码进行身份验证,而不会使用第三方应用(可能是恶意的)来获取密码(并将其转发给狡猾的naer-do -好)

有效期:

代币有点危险.有权访问令牌的任何人都可以像您一样登录.那么,这里的好习惯:

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

  • 因为那时任何在传输过程中拦截和存储哈希的人都可以从任何地方永久地登录.你有没有使用过免费的wifi热点?热点的所有者和使用它的每个人都可以看到并记录您传输的每一个位.它已在该领域得到证实.有关窃取Facebook凭据的明显示例,请参阅http://codebutler.com/firesheep.请注意,这甚至会窃取auth cookie.使用auth cookie,当服务器更新cookie时,它们将失去访问权限,但是使用用户名/密码哈希,他们可以访问,直到您更改密码. (3认同)