Warning: file_get_contents(/data/phpspider/zhask/data//catemap/8/mysql/62.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Android SyncAdapter服务器端实现_Android_Mysql_Synchronization_Android Syncadapter - Fatal编程技术网

Android SyncAdapter服务器端实现

Android SyncAdapter服务器端实现,android,mysql,synchronization,android-syncadapter,Android,Mysql,Synchronization,Android Syncadapter,我已经阅读了很多关于同步适配器的教程,比如上的教程以及Android开发者网站上的SampleSyncAdapter示例代码。 但我不明白服务器端如何处理身份验证和同步查询。我是否可以使用php从mySQL服务器数据库进行查询 您缺少的部分不是同步适配器的一部分。这是最重要的。它是一个处理用户密码并将其传递给服务器的类,它的编写方式必须与所讨论的服务器相匹配 方法: 首先,这个过程是如何工作的 用户在设置->帐户和同步页面上输入用户名和密码 (稍后…)同步过程开始 SyncAdapter调用bl

我已经阅读了很多关于同步适配器的教程,比如上的教程以及Android开发者网站上的SampleSyncAdapter示例代码。
但我不明白服务器端如何处理身份验证和同步查询。我是否可以使用php从mySQL服务器数据库进行查询

您缺少的部分不是同步适配器的一部分。这是最重要的。它是一个处理用户密码并将其传递给服务器的类,它的编写方式必须与所讨论的服务器相匹配

方法:

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

  • 用户在设置->帐户和同步页面上输入用户名和密码
  • (稍后…)同步过程开始
  • SyncAdapter调用blockingGetAuthToken()
  • AccountAuthenticator启动
  • AccountAuthenticator使用常规http(或理想情况下,https)身份验证连接到服务器,并且一旦身份验证,就从服务器请求“令牌”。此令牌是一个大的(比如128位)随机数,只有在使用基于密码的身份验证登录时才能从服务器获取
  • AccountAuthenticator缓存令牌,然后将令牌返回给SyncAdapter
  • SyncAdapter尝试访问服务器上的内容,并在其请求中作为http头的一部分传递令牌
  • 服务器接受令牌代替正常的http身份验证,并允许服务请求
  • 未来的同步尝试最终将跳过此过程的大部分。在以下同步尝试中,当SyncAdapter调用blockingGetAuthToken()时,AccountAuthenticator只返回缓存的令牌,无需重新验证
  • 所以这个令牌的使用是有限的——过一段时间,服务器将拒绝接受它。此时,SyncAdapter尝试使用令牌,并收到身份验证错误。那又怎样

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

    因此有几个优点

  • 普通http身份验证通过internet以明文形式传输密码。如果使用令牌,则只发送一次密码,多次发送令牌。这在一定程度上减少了将密码暴露为嗅探
  • https身份验证避免了明文问题,但在移动连接方面可能会很昂贵。使用令牌可以为实际携带数据的服务器调用提供更轻量级的http连接,https开销仅在获得令牌后的第一个请求中出现
  • 隔离——AccountAuthenticator知道用户的实际密码。SyncAdapter仅获取对令牌的访问权限,而从不学习密码。这对谷歌来说很重要,因为它允许第三方应用程序使用gmail帐户和pasword进行身份验证,而无需第三方应用程序(可能是恶意的)获取pasword(并将其转发给不正当的用户)
  • 到期日期:

    代币有点危险。任何获得令牌访问权限的人都可以以您的身份登录。因此,这里的良好做法是:

  • 服务器应该在一段固定的时间后使用户的令牌过期。更多的偏执——更短的暂停时间
  • 每当用户更改密码时,服务器应使用户的所有令牌过期
  • 如果用户在上,则服务器可能不会使分配给web设备的令牌过期 web界面将注销。代币并没有真正的“注销”概念
  • 服务器应该考虑将令牌绑定到首先请求它的IP地址,然后如果不同的IP地址随后尝试使用该令牌,则拒绝令牌(但不一定过期)令牌。如果你这样做,服务器肯定需要能够为每个用户创建多个令牌(每个用户一个令牌:IP地址组合)——考虑一个带有两个移动设备的用户——没有这个,每次一个同步,它将使另一个令牌无效。同时考虑家用WiFi上的两种设备(在路由器后面共享一个ip地址,然后一个设备离开并开始使用移动网络——这就是为什么您可以选择不过期,这样仍在家中的设备可以继续使用令牌。但是,漫游的一个设备将看到身份验证失败并建立自己的新令牌。当它回到家中时,服务器将uld确保提供已为该IP地址建立的相同令牌。) <> LI>根据您的偏执狂级别,无论如何只考虑在HTTPS上接受AuthToCon。这是一个被盗的AuthToT可以得到的一个很好的例子。如果你有用户敏感的数据,你应该只接受HTTPS。而且,即使你没有用户敏感的数据,你也可以考虑编写一个要求HTTPS改变DB W的协议。允许http读取
    为什么你不能每次都对用户名和密码进行散列并发送它呢?跳过一些步骤,这在我看来是愚蠢的。因为这样,任何在散列传输过程中拦截并存储它的人都可以像你一样从任何地方永远登录。你曾经使用过免费的wifi热点吗?无论是热点的所有者还是每个人使用它,可以查看和记录您传输的每一位信息。这在现场得到了验证。请参阅,以获取一个涉及窃取Facebook凭据的显著示例。请注意,这甚至会窃取身份验证cookie。使用身份验证cookie,当服务器更新cookie时,他们将失去访问权限,但使用用户名/密码哈希,他们将拥有访问权限,直到您更改密码除非你在肉馅上撒盐,