OS: Ubuntu 10.04 LTS
pgAdmin: 1.14 source code

Install:

./configure
make
make install

Trouble shooting:

1. configure: error: Could not find your PostgreSQL installation. You might need to use the --with-pgsql=DIR configure option

apt-get install libpg-dev

2. configure: error: Could not find your wxWidgets installation. You might need to use the --with-wx=DIR configure option

apt-get install wx-common libwxgtk2.8-dev

3. configure: error: Could not find your libxml2 installation. You might need to use the --with-libxml2=DIR configure option

apt-get install libxml2-dev

4. configure: error: Could not find your libxslt installation. You might need to use the --with-libxslt=DIR configure option

apt-get install libxslt1-dev

5. ./db/keywords.c:33:27: error: parser/kwlist.h:...

apt-get install postgresql-server-dev-8.4

推送到[go4pro.org]

不过倒是在Nokia展台看到了刚刚发布的Lumia 800和710。不过这个新机人气太旺了，排了半天队才能玩上一把。

硬件上没什么好说，Nokia的做工是没得说，至于扛不扛摔没试过，不知道。我关心的重点还是它们所用的WinPhone7芒果系统。

对于芒果来说，最吸引人的莫过于Metro UI了。不得不承认，这个UI的确是创造性的，按aawolf兄的话说就是：Android/iOS那些一堆图标的UI都是普通范，Metro UI这种才是文艺范。

在 我看来Mango的UI第一大特点就是图标大多了，并且变成了瓷砖样的拼图——事实上微软貌似就是管它叫瓷砖（Tiles）。但这只是表面现象，重点在于 这些Tiles本身也变成了信息显示的界面，而不再只是代表Apps的图标而已。基本上在WP7里的Tiles有点像是Android里的桌面 Widget，但又比Widget更充分地利用显示面积。不过这种Tiles的交互能力比Widget还是差点，我只看出它有显示功能，没看出有交互功 能，当然也可能是我没有试出来。另外，与图标对应的Apps也还在，只不过是隐藏在一个需要单独弹出的列表里。

而这个UI另一大亮点是全景视图。具体来说就是一个应用的界面可以做成一个比屏幕大得多的虚拟视图，然后滑动浏览——虽然别的手机上显示超 大的视图（比如放大图片）也可以滑动浏览，但是基本上应用的显示大小还是局限在屏幕大小的范围内，滑动浏览不过是放在一个ScrollBox里而已。但 Mango这个是直接就是一个大视图，而且滑动提示也很有意思，是把屏幕以外的内容在当前屏幕上显示一小部分，这样任何人看到都会直接想到屏幕外还有内 容，自然就滑动过去看了。

这种以人为本的操作隐喻坦白说太有水果范了，但居然不是出自水果而是微软。不得不说自Kinect以来，微软的创新力量似乎开始爆发了。

另外，手机整体的操控流畅性非常好，这应该是因为WP7对于硬件配置有最低要求。水果更不用说，软硬件一体。Android在这方面就不行了，多烂的硬件都有装Android的，搞坏了Android的形象。

因为WP7完全使用.net托管代码，从性能角度上说，其实应该跟Android用的JAVA是一个级别的，但因为有硬件最低配置限制以后，可以有效避免操作流畅性问题。这个做法相当可取。

还 有一个方面就是，全新设计的WP7完全摆脱了WM的阴影——我接触WM很少，但即使是这样有限的接触，也对它是完全没有好印象，把桌面上经验硬移到移动上 是完全错误的一条路。当然也只有像微软这样的公司能这样干，可以把投资多年的WM一举放弃推倒重来。WP7是一个完全的移动OS，摒弃了WM上的错误思 路，因此对性能操控等各方面的改进应该说都是很大的。

当然，几分钟的把玩，了解显然是肤浅的，不过还是部分改变了我以往的成见。微软的进步的确是明显的。

然而对于Nokia，我仍然不看好，它已经正式沦为一个硬件代工厂商了。不过这也是迟早的事，作为之前用了Nokia手机近十年的人，我一直都认为他们做的软件一向很烂，现在把软件的工作交给微软去做也许是件好事吧。至少对微软来说是好事。

关于WP7的开发技术，主要是听了aawolf的讲座后了解了一些。如上篇所说，很遗憾地因故没能听完，不知道CSDN能不能提供视频或PPT下载补习一下。

如前面所说，WP7是完全使用.net托管代码的，这点上可以说微软终于兑现了十年前的承诺：一个完全.net的OS。

在 版权保护方面，微软是完全跟水果站在一边的，为应用的防盗版提供全方位的保护——同样的，对应用的开发也加以了全方位的限制。在这点上我觉得微软比水果走 得更远。利弊还不好说，但相比之下Android——特别是某些第三方或中小硬件商的自制ROM实在是问题多多，在这点上Android的确有很大的潜在 问题。

另外就是安全性方面。WP7启用了最高级别的安全保护，据说相当于在WIN7里把UAC的安全级别设置到最高，对于发短信打电话之类 的功能都会弹出提示要求用户确认，而且这个警告是集成在系统中，应用程序无法绕过。这点的好处是明显的，避免了应用程序可能使用的绝大部分的流氓行为，但 我觉得过多的提示也可能会造成用户的体验下降，其间的得失还要看市场的反应了。

还有就是图形方面，WP7上提供的官方技术是SilverLight。不过我不确定这是不是唯一的选择。

总的来说，WP7是一个相当不错的手机OS，甚至可以说，在某些方面的确超越了iOS。也的确比较适合不怎么爱折腾的Nokia用户。与桌面开发一致的开发环境可以为它带来大量的应用开发者。这些都是WP7的优势所在。

至于WP7及后续的WIN8等会如何发展还是很难说的，理由主要有几点：

首先一点就是，通这次的初步了解，我没有看到WP7有什么杀手级的功能——Metro UI确实不错，但界面效果毕竟不是实用功能，用户买手机是拿来用的，而不只是看或玩它花哨的界面。其次，应用程序少的起点短期内难以改变，加上微软加上了 这么多限制，使得相当部分的应用其实没法搞。另外，我也一直都不看好SilverLight，尤其是如果它是WP7上唯一的选择的话。

相比之下，水果每代产品都有至少一项杀手特性出现，加上周边的服务，以及他们对用户的领导作用，iOS的优势可以说在较长的时期里都是无法撼动的。

而 Android方面，开放的体系结构可以拉拢足够多的中小厂商。至少在中国，有将近一半的市场是被山寨机所占领的。就中高端来说，可能会有变数，一方面是 要看市场对Android4的表现，另一方面则是Google与Moto的关系——这方面可能更为主要，一旦处理不当，得罪了三星和HTC等大厂商，他们 未必不会在中高端转向微软，毕竟他们也一直跟微软是有合作的。

压力最大的无疑是Bada这样的三流系统，它们无论从哪个角度上看，跟WP7都完全没有可比性，注定会是杯具。至于WebOS虽然不错，但终归已经被HP所抛弃，前景渺茫。还有RIM就不提了，再不振作起来怕是也没戏了。

除此之外，WP7的最大市场还在于Symbian让出的这一块，能在这些用户流失前争取到多少，决定了WP7及其后续版本的前途。当然目前看来应该还是比较乐观的。

================补充的分割线===================

另 外在作本文的时候，在推上看到一则对WP7很不利的传闻：据说在Nexus One上装MonoDroid跑WP7应用结果性能比在最新的WP7手机上还要好。Nexus One已经是将近两年前的硬件了，如果这是普遍现象的话，可能说明WP7还太新，某些方面还不够成熟。当然，我还没看到具体的测试，也可能只是个别应用本 身的优化问题。

另外，最新的消息相信大家都看到了，Adobe宣布放弃在移动和电视领域继续支持Flash，估计离全面放弃也不太远了。微软是继续死守淫光，还是转向HTML5，这是个问题。

推送到[go4pro.org]

不过因为准备不够充分，第一天出了门才知道8号线停运，结果路上绕了点路，迟到了一小时，到的时候已经是蒋总讲话了，错过了李开复的讲话。

微软的张亚勤演示了未来移动应用的美好景像的确是很美好，不过在我看来，技术和非技术的障碍还是很多的，只能作为一个美好的愿景来看，暂时还当不得真的。

上午的亮点是申音主持的论坛，跟腾迅的刘总和华为的徐总讨论得很热烈，逼得刘总说出了微信的真实用户数范围：3000万到1亿之间——之前网上风传的1.8亿大家是不信的，但真实数据不知道，现在总算有准数了。

徐总则更是直接说国内这些Android ROM都是修修补补敲敲打打出来的货色……要知道接下来一场就是国内最著名的Android ROM——MIUI的，人称雷布斯的雷军的演讲。

可惜接下来的雷布斯并没有直接回应徐总的挑战，甚至没有讲他关于移动电子商务的主题，只是匆匆说了几句关于创新的自己的观点，也不知道算不算是曲线应战。不过坦白说，我是不太同意雷布斯的观点的，抄袭就是抄袭，所谓的微创新就是修补敲打，在这点上，徐总说的没错。

下 午的亮点是百度的王总。来自百度的很多数据很有意思，不过有些也是挺囧的。比如据说据百度统计，来自Android和iOS的流量加起来只有10％，相应 的，有48％的流量却是来自于MTK。王总对此的解读是：智能机的市场还处于将爆发而未爆发的潜力状态。但听众们似乎都不同意，至少在我看来，这个数据只 能说明：百度更受山寨机用户的欢迎，而Android/iOS用户大多不屑于使用百度罢了。

MOTO的沈总那真是侯总附体，完全是到现场来卖手机的。不过新出的Razr XT910的确很NB，据第二天去参加了MOTO发布会把玩过真机的四万姐说，的确很强悍。这个号称最薄、凯芙拉后背、可以水洗的刀锋手机不知道啥时我能有机会试试。

第二天的会议内容相对前一天要更加具体一些，我主要是在一号会场听一些技术专题，不过其它场也偶尔去看看。

技 术方面分歧就很大了，是HTML5还是原生？原生的话选哪一个或几个平台？Android、iOS，还是WinPhone7、Bada等。不过市场占有率 的差别是很明显的，Android讲座之后是Bada，瞬间听众走掉不止一半。坦白说，我在三星的展台试玩了一下几台Bada系统的手机，完全看不出比 Android有什么优势，加上太少的市场占用率，的确难以吸引开发者分心去为它作开发。据说讲座后有听众挑战讲师，质疑Bada平台所用的硬件系统较其 它平台落后一代（大概是要以此来获得价格优势），结果貌似闹得不太愉快。

可惜我没有看到，因为我在讲座结束前去了三楼的2号会场，想看看糗百的讲座，结果也没看到，不知道是因为前几个演讲者拖时太厉害还是演讲顺序临时调整过了。只好去看了5号会场的LBS与电子商务论坛。

单从听众的火爆程度来看，Android/iOS无疑是目前最受开发者关注的平台。新出的WinPhone7也号召力很高，毕竟有MS和Nokia两个巨头挟大批历史积累下来的开发者在。

下午去看了宝开介绍PvZ的开发历程，有点意思。之后去看了韩磊主持的媒体论坛，居然还出了糗事，哈哈哈。然后就基本上一直在技术会场。

两场关于iOS的介绍不错，可惜我没做过iOS开发，不然应该会更有收获。期间顺便还给四万姐和冯大辉拍了张合影。不过可耻的是当时没认出冯来，过后才知道是他。前几年我们还在CSDN英雄会上见过的。囧。不过相比那次在吴淞口没认出人的糗事，那才真是糗。

关 于iOS5的讲座，还有个有意思的事情就是：讲师谈到siri目前因为手机上的存储和运算能力不足，实际上AI是在云端处理的，然后就有观众突发奇想，问 他siri的云端智能是不是有可能演化成Skynet（电影《Terminator》系列里消灭人类的智能计算网络）。他的理由是有那么多水果手机分散在 世界各地，每个手机里有那么多各种传感器，理论上siri的云端对于世界能够有充分的感知能力，加上它超强的AI能力，未必没有这种可能性。但我还是觉得 他想得太远了……

接下来是我最关注的一个技术讲座就是aawolf兄讲的关于WinPhone7的，具体的我想回头另外再细说。不过可惜的是因为要见朋友，这个讲座没能听完，很遗憾。

总的来说这次大会还是很好很成功的。

坦白说，在移动开发领域我还是个菜鸟，不过这次进京看到很多以前做桌面应用的朋友都纷纷转向了移动应用开发，很明显大家都感受到，移动市场已经爆发。相信未来在这个领域必将有更多的机会和挑战。

当然也很高兴能有这样的机会在会上见到一些老朋友，比如四万姐、老妖、可儿等，也见了做主持人的韩磊和作演讲的aawolf，只是没机会打招呼，可惜以前认识的一些CSDN的朋友如伴水等都已经离开了，这个比较遗憾。

最后提点建议吧：现场座位不够是个问题，很多人都不得不站着听，两天下来还是挺累的。

另外，第二天的几个分会场分得太开，几个场来回跑也是很吃力的事情。

再有就是作为程序员，我觉得技术讲座还是太少了，不如SD2C。

最后就是现场没有可用的WIFI网络也是很不方便的。

推送到[go4pro.org]

foursquare 第一版的API是基于BasicAuth的，也就是基于HTTP Authentication的一种基本验证方式，这种方式的优点是非常简单，只要在HTTP Header里加一个字段就行了，但缺点是用户名密码会被直接暴露在传输过程中，虽然经过了Base64编码，但是解码它是一件非常容易的事情，除非使用 HTTPS，否则是非常不安全的。

之前因为我用的手机是智障机，跑不了官方客户端，官方网页端又被墙，用起来很不方便，所以自己参考了dabr的代码，用PHP4写过一个网页客户端程序。

不 过后来foursquare出于安全和功能考虑，完全抛弃了第一版的API，推出了全新的第二版API。这个版本的特点是：完全重新设计了API的架构， 更加符合REST规范，特别是身份验证改用了更安全的OAuth 2.0，并且使用了HTTPS。到今年8月1号的时候，foursquare关闭了对第一版API的支持，全面转到第二版API。为了让我的程序能够继续 使用，我不得不赶在这一转换之前几天，把程序完全改写了——顺便增加了一些功能。

当然，本文不打算详细讨论foursquare的API，只谈谈登录的部分。

根据foursquare的Authentication文档说明，全部的过程可以分为三大步：

1、在foursquare注册一个应用，取得一个client_id；

2、通过OAuth 2.0验证，取得access_token；

3、使用access_token调用foursquare API。

其中第一步没什么好说的，照着说明去做就是了，这里要从技术上讨论的主要是第二步，并且需要用第三步来验证第二步的结果。

单就第二步取得access_token来说，也可以分为以下步骤：

1、 先转向到foursquare的授权页面，并提交client_id和redirect_uri（其它参数见文档或代码）。redirect_uri为验 证通过后的回调链接，即在注册应用时提供的那个回调链接，通常二者需要保持一致，不过只要client_secret保管好，即使这里允许不一致（说明： 我倒没试过不一致会如何）也不会导致client_id被盗用；

2、foursquare收到请求后根据以下情况作出判断：如果你还未登录foursquare，则提示你登录；如果你已经登录，但未授权此应用，则提示你是否要授权；如果已经授权，则重向到redirect_uri，并同时提交一个code；

3、 应用收到转来的请求后就可以向foursquare请求获取access_token了，请求参数包括 client_id，client_secret（相当于应用密码，这个一定要保管好），code等（其它参数见文档或代码），只要这个code没错，就 可以取得access_token。

之后就可以用这个access_token去调用foursquare API了。

需要注意的是：这个access_token是一个用户对一个应用授权的唯一标识，一定要保管好，不可泄露。当然，如果万一泄露，应用的开发者应该及时到foursquare的应用管理页面重新生成client_id/client_secret。

具体的登录代码如下：

function login_foursquare() {
  session_start();
  
  $GLOBALS['user']['type'] = 'oauth';
 
  $oauth_code = $_GET['code'];
  if (isset($oauth_code)) { // 来自foursquare的回调请求含有code参数
    $params = array('client_id'     => OAUTH2_CLIENT_ID,
                    'client_secret' => OAUTH2_CLIENT_SECRET,
                    'grant_type'    => 'authorization_code',
                    'redirect_uri'  => CALLBACK_URL,
                    'code'          => $oauth_code);
    $result = do_sf_process(SF_OAUTH2.'access_token?'.http_build_query($params)); // 向foursquare请求access_token
    $access_token = $result->access_token;
    
    $redir = $_SESSION['redir'];
    unset($_SESSION['redir']);

    $GLOBALS['user']['password'] = $access_token;
    
    sf_user_info();
    _user_save_cookie(1);
    header('Location: '. $redir);
    exit();
  } else { // 来自用户的登录访问，不含code参数
    _user_decrypt_cookie($_COOKIE['USER_AUTH']);

    $redir = isset($_GET['redir']) ? $_GET['redir'] : $_SERVER['HTTP_REFERER'];
        
    $_SESSION['redir'] = $redir;
    
    $authorise_url = SF_OAUTH2.'authenticate?'.http_build_query(
        array(  'client_id'     => OAUTH2_CLIENT_ID,
                'response_type' => 'code',
                'redirect_uri'  => CALLBACK_URL));
    header("Location: $authorise_url"); //  重定向到foursquare的授权页面
  }
}

至于取得access_token以后的API调用，所要做的事情就只是把access_token附加到每次调用的参数里即可。

function user_oauth_sign(&$url, &$args) {
  $method = $args !== false ? 'POST' : 'GET';
  
  if (preg_match_all('#[?&]([^=]+)=([^&]+)#', $url, $matches, PREG_SET_ORDER)) {
    foreach ($matches as $match) {
      $args[$match[1]] = $match[2];
    }
    $url = substr($url, 0, strpos($url, '?'));
  }
    $args['oauth_token'] = $GLOBALS['user']['password'];
    if ($method == 'GET'){
        $url  = $url."?".http_build_query($args);
        $args = false;
    }
}

function sf_process($url, $post_data = false) {
  if (user_type() == 'oauth' && (strpos($url, SF_API) !== false)) {
    user_oauth_sign($url, $post_data);
  }
  $result = do_sf_process($url, $post_data);
  return $result->response;
}

整个客户端代码下载在Google Code。

推送到[go4pro.org]

虽然自己写的BLOG都是些没营养的东西，但还是想收藏起来。

花了点时间研究了一下epub格式，写了段转换程序，把Wordpress导出的备份文件WXR转成epub格式。

本想贴代码凑数，结果发现代码还是多了点，所以还是改成下载吧。

第一个是生成epub的库：epubbuilder.py

（源码附后）

之后是解析WXR并调用epubbuilder生成epub的主程序：wxr2epub.py

（源码附后）

下载：wxr2epub source code 5.4K(GPL)。

使 用时在源目录下放一个叫做wordpress.xml的WXR文件，再创建一个images的子目录，里面放上文章中所有引用过的图片，最好有一个叫 cover.jpg的，这个图片将会被作为电子书的封面。生成的电子书每一篇文章及其评论会作为电子书的一个章节，文章多的话，目录项会很多，某些电子书 软件可能无法完全显示所有目录项。

所以说，还是开放好啊。Wordpress的WXR用的是开放的XML格式，epub也是用开放的zip＋HTML＋XML格式。

像CSDN BLOG这种自己开发的平台就没办法了……当然也不是完全没有办法，可以自己写一个爬虫去把页面全抓下来，再用pyquery之类的解析出内容，然后生成 epub。不过这就麻烦得多了，除了程序写起来麻烦以外，还要防止爬得过猛被网站封IP之类的副作用——这事我也干过，不过不是对CSDN。

推送到[go4pro.org]

@liumiao: 据说新款MOTO的铃音是：“Hello，谷歌。”

我KUSO了一下，于是就是这个标题：哈，露股沟。

大致看来下，大家的分析有几大原因：

首 当其冲的自然最近GOOGLE最头痛的专利问题。老家伙们手里都握着大把的专利，对GOOGLE这样的专利少的后来者的确非常不利。而落后的专利制度已经 沦为大公司和专利律师们的摇钱树，而不再是创新的激励机制（关于这一点网上已经有太多达人的论证，我就不COPY了）。

其次当然是想向水果学习，搞垂直整合。可能是GOOGLE对之前由HTC代工的Nexus One和三星代工的Nexus S还是不够满意，所以决定卷起袖子自己干。但问题是水果也只是自己设计，然后交由富士康来干，并不是自己干的。

还有人提到的就是《微软挪鸡鸭》。微软迟早是要以250亿收购Nokia的（@doubleaf对此句亦有贡献），GOOGLE抢先把MOTO收了，占个先机。

除此之外还有各种说法就不一一列举了。

至于这么做到底好不好，各方的说法就分歧很大了。

作 为Android用户来说，大多认为这是一件好事。因为现在市场上的Android手机实在太乱了，各种硬件配置，各种屏幕分辨率，各种系统版本，各种 UI修改，让人眼花缭乱。基本上就我个人来说，除了少数GOOGLE嫡系机，别的我都觉得敬而远之为好，所以我自己最后是入手了Nexus S。现在GOOGLE直接切入制造层，显然有可能会推出更好的Android手机，所以应该会是好事。

关于Android手机的混乱，我之 前也只是有耳闻，没啥见识，加上自己是直接入手NS这种嫡系机，刷了个CM7，感觉还是挺好用的，没感觉到传说中Android的各种缺点。不过前一阵弄 了一只Moto XT800+，传说中的电信定制机。虽然硬件配置相当高端，内存比NS还要大，还双模双待，但是用起来各种不顺畅，BL被锁又不能刷第三方ROM，传说中 的Android各种毛病果然都有，最可耻的是作为Android手机，居然没有GOOGLE的全套服务（全都被换成了MOTO的和电信的一大堆垃圾）， 真心不爽啊（当然，花了点时间还是把它搞定了）。这还是三大Android制造商之一的Moto产品（当然中国电信对此功不可没），除五大（三 星，HTC，MOTO，SE，LG）以外的其它中小制造商的产品还不知道会是什么样。

这样的混乱局面必须得到整顿。这大概是GOOGLE收购MOTO可能需要达到的目的之一，也是可能得到的好处之一。

另 外一方面的好处自然就是专利——事实上目前GOOGLE官方公布的消息称，专利就是此次收购的主要目的。之前HTC因为被水果专利敲诈，不得不咬牙收购了 S3，以获得它手里的专利作为应对手段。现在GOOGLE如果能够以MOTO的专利储备为基础，整合各制造商的专利资源，联合对付水果和微软的专利战，估 计胜算会大很多，毕竟MOTO是移动通信的创立者，手里握着大把移动通信技术的专利。

至于说收购MOTO以对付MSN（OKIA）大概是不 在考虑之中，NOKIA现在都自身难保（最新的消息称NOKIA在中国的渠道已经崩溃，而中国市场占到其总业务量的20％），估计已经不被GOOGLE放 在眼里了。不过GOOGLE这次收购倒是帮了NOKIA的忙，大家都觉得它要被MS收购了，股价大涨。

不过不看好的也很多。

大 家首先想到的就是其它Android设备制造商。GOOGLE此举无疑是来抢他们的饭碗，他们不可能无动于衷。很多人因此看好MS，认为这些制造商可能投 向WP7一边，毕竟像HTC和三星曾经都做过WM的手机。当然GOOGLE官方不这么认为，有五大Android制造商中剩下的四大发来的贺电为证（来自Larry Page的G+）：

Quotes from Android partners

“We welcome today’s news, which demonstrates Google’s deep commitment to defending Android, its partners, and the ecosystem.”
– J.K. Shin
President, Samsung, Mobile Communications Division

“I welcome Google‘s commitment to defending Android and its partners.”
– Bert Nordberg
President & CEO, Sony Ericsson

“We welcome the news of today‘s acquisition, which demonstrates that Google is deeply committed to defending Android, its partners, and the entire ecosystem.”
– Peter Chou
CEO, HTC Corp.

“We welcome Google‘s commitment to defending Android and its partners.”
– Jong-Seok Park, Ph.D
President & CEO, LG Electronics Mobile Communications Company

实际情况还是要看未来的实际发展，Google当然会说他们会保持开放，对包括MOTO在内的所有制造商一视同仁，但对于用户来说，可能还是会倾向于选择GOOGLE＋MOTO的产品——至少我是如此。

不 过我觉得看问题不能只从自己的角度来看。各厂商毕竟还是有各自的优势和特色。当初Nexus One的供应是比较紧张，但是现在Nexus S在市面并不缺，价格也不贵，却并不是所有人都会选择它，甚至有很多人不喜欢它。所以其它厂商并不是没有机会——只要GOOGLE信守开放的承诺，相信其 它厂商还是会看市场下菜的。

当然如果市场真的转变向GOOGLE＋MOTO一方，那也说明那时候G+M已经有足够向水果挑战的实力了，其它厂商即使转向MS也捞不着什么好处，还不如继续跟着GOOGLE混。

至于现在三星HTC之流转向MS也不是不可能，问题就在于MS会不会收购NOKIA？如果收购了，那么转过去的结果也是一样，还不如不转。而且就现在的情行来看，就算是MS不收购NOKIA，以MS和NOKIA亲密合作的态势来看，他们投过去未必能比不投好到哪里去。

这样看来，这四大制造商的表态多少还是应该有部分是发自真心的——至少是无奈的真心。

就我个人来说，会更加看好Android，因为有MOTO经验支持，未来的Android系统应该能够更好，而有了GOOGLE的支持，未来MOTO应该会造出更好用的手机。

最后BTW一下：MOTO的BL快要可以解锁了吧？

OpenID

OpenID 是一个开放的Authentication解决方案，关 于OpenID，我在06年的文章里已经谈过，不过那时谈的是最早版本的OpenID，也不知道是哪个版本，现在用的主要是OpenID Authentication 2.0及其周边的一些扩展功能。OpenID Auth 2.0基本原理与以前的版本没有本质的变化，只是在安全性和一些细节功能上有所增强。

基本的OpenID Authentication登录流程如下图：

1、首先用户在依赖方（即第三方网站）输入其OpenID URL进行登录（也可以直接使用提供方ID登录，这种方式则没有第2、3步）；
2、（可选）依赖方从用户OpenID URL的页面中执行自动发现；
3、取得OpenID提供方的End Point URL；
4、（可选）依赖方与提供方建立关联；
5、取得关联的约定加密信息；
6、重定向用户浏览器到提供方；
7、用户登录到提供方并授权第三方的认证请求；
8、返回认证结果（是否通过用户身份验证）；
9、重定向用户浏览器到依赖方，并提交认证结果；
10、依赖方向提供方验证用户提交的认证结果；
11、通过用户认证。

之 后，依赖方可以保存第9步的用户提交信息，在每次需要验证用户身份的时候，重复第10和11步向提供方验证用户身份。通常这项工作由session实现。 因为这两步需要多次进行，为了安全需要每次都必须进行签名验证，所以通常还是建议使用第4和5步的建立加密关联，以方便后续的验证操作。

过 程中的第2和3步就是OpenID分布式的关键，也是我在旧文中认为的OpenID的缺点（或者说是特性）之一。这一步可以让用户不受具体的提供方所限， 使认证成为分布式，但同时也使用用户的认证可靠性受这个OpenID URL对应的网站所限。所以现在很多OpenID认证应用都直接跳过这一步，使用固定（或有限可选的几个）提供方进行登录，使之从分布式身份验证成为第三 方集中式身份验证。其实我个人认为这样更好一些。而且这样还可以减少一对网络round trip，有助于改善登录速度。

在这一基础 Authentication之上还有一些额外的约定，基 本的OpenID Authentication在验证通过以后，除了返回验证通过信息以外，还可以同时返回用户的Profile。当然，一般的Provider可以由用户 选择验证返回的Profile内容，比如myopenid.com可以选择返回一个完整Profile或是一个空白Profile（但仍然返回验证通过信 息）。那么关于个Profile就需要有一定的协议来约定。

在OpenID 2.0中主要是两个：简单注册扩展(Simple Registration Extension)和属性交换(Attribute Exchange)。

简单注册扩展约定了Profile的8个字段，实现起来较为简单。属性交换则更强大一些，可以双方约定任意数量和内容的字段，实现起来略复杂一些。

这也是Google提供给第三方的OpenID登录方式就是采用了属性交换约定。

属 性交换的功能就是在依赖方提交验证请求 的 同时告诉Provider它需要哪些用户Profile信息字段（称为属性），然后用户在通过验证时，Provider将依赖方请求的属性告诉用户，由用 户决定是否允许（只能允许或拒绝，如果拒绝则验证不通过，不提供空白响应的选项）。

属性交换除了可以用于读取所选属性，还可以用于存储属性，当然这需要Provider方支持。

Google提供给第三方的OpenID登录流程如下图：

以上就是关于OpenID的基本介绍，具体的实现可以到官网下载各种语言实现的源码研究。

OAuth

OAuth是一个开放的Authorization方案，可以说是基于OpenID发展起来的。因为OpenID不能提供Authorization功能：

比 如某网站A提供了允许用户用TA的OpenID登录，但是如果某网站B需要用到网站A中该用户的数据，就无法通过OpenID来实现将网站A中的用户数据 安全地授权给网站B——虽然可以让用户把自己的OpenID信息提供给网站B，让它以用户的身份登录网站A去取得，但这样的话如果网站B是一个恶意网站， 它就可以以用户的身份登录任何其它支持该用户以OpenID访问的网站，带来严重的安全隐患。

于是人们需要一个开放的Authorization协议，于是OAuth诞生了。

目前OAuth有两个几乎完全不同的版本：OAuth 1.0和OAuth 2.0。

OAuth 1.0是一个被设计得非常安全的协议：除了Provider与Consumer之前的验证过程是相当安全的以外，它甚至要求对每一次的数据请求（API调用）都要进行请求内容的数字签名，以确保万无一失。

而OAuth 2.0则相当于对OAuth 1.0作了很大的简化：Provider与Consumer之间只是简单地交换一下密钥Key进行验证，之后Consumer只需要凭借验证后取得的一个Token就可以进行数据请求（API调用），没有太多的签名校验工作。

从技术上说，两个版本都可以实现Authorization功能，二者的差异在于：1.0更安全，但代价也更大（验证过程复杂，请求过程复杂）；2.0更方便，但是安全性不如1.0（比如请求可能在传输过程中被修改）。

个人倾向于建议使用OAuth 2.0+HTTPS的方案，这样可以降低编程的复杂度，减少出错的概率，同时通过HTTPS保障安全性。

实现

关于以上相关技术的实现，有空再来做吧。暂时计划包含：Google OpenID, Twitter OAuth 1.0, Foursquare OAuth 2.0

推送到[go4pro.org]

第一个案例是几天前，我收到一位朋友的邮件，邀请我加入一个叫ShoppyBag的网站。我去看了，没想到注册后就让我登录GMail帐号，并且GMail提示我该网站需要访问我的通讯录，于是我当即就中断了注册过程。

对于这类需要访问我的邮箱通讯录的网站我都是非常厌恶的，无数的垃圾邮件就是来自于它们。它们通过访问你的邮箱通讯录，然后向你的联系人们发邮件，然后迅速扩大了用户量可以向VC骗钱，而用户的隐私就这样被卖掉了，更不用说那些不请自来的垃圾邮件。

当然，虽然我中断了注册过程，但用户是已经注册成功了，只是访问网站时还会不时地提示我登录GMail。仔细看了它的提示内容后，发现有一行小字写着：

Your email address book contacts will be imported to your ShoppyBag Address Book.
ShoppyBag will not store your email login information or contact anyone without your permission.

我当然知道这种登录方式这个网站不会取得我的邮箱登录信息，它也可以假装未经授权不向我的联系人发邮件，但是我完全不想把我的通讯录COPY一份给它，因为只要那东西在它手上，我就不能保证它会拿来干什么。

之后还收到别的朋友也发来这个网站的邮件，而且在People You May Know里也看到很多熟人，不知道其中有多少人是中招的多少人是相信了这个网站的。

总之我是不信任这类网站，并且不会把通讯录授权给它们的。反正对这类SNS我也没什么兴趣。

这 个网站之所以可以取得用户的GMAIL通讯录，但是又不需要知道用户的密码，就在于它使用了GMAIL的一个授权（Authorization）功能的 API，当用户被定向到GMAIL登录页面时，用户选择允许以后，这个网站就可以通过GMAIL的通讯录API取得用户的通讯录了。

第二 个 案例是在豆瓣小组，有人发布了一个他自己做的网站，因为要注册，我懒得去看，后来他说支持GOOGLE帐号登录，我就想去看看。结果是一登录GOOGLE 帐号就提示说这个网站要访问我的GMAIL通讯录。基于前所说的原因，我就把这个帖子给封了，那个楼主就发来豆邮兴师问罪。说是第三方用GOOGLE帐号 登录就是会这样的，但是很不幸我刚好最近也研究过这一块东西，知道并非如此。

所以我们需要先搞清楚一个问题，那就是认证和授权的区别。

Authentication和Authorization的区别

As we know，用户管理功能是大部分网站的基本功能，而这其中基本的基本就是用户身份验证，简单说就是登录——也就是“如何证明‘你’就是‘你’”。这就是所谓的Authentication。

用户管理的另一个基本部分（这个部分虽然基本，但不是必须的）则是权限管理——也就是“‘你’可以干什么”。这就是所谓的Authorization。

前 面两个例子中，第一个例子就是一种第三方Authorization，它试图让用户授权给它访问用户通讯录的权限。第二个例子则是错误地使用了 Authorization进行Authentication操作——当然，这里是以善意的角度来看这个网站，要是从恶意的角度上说，也可能它就是要用这 种方式来获取用户通讯录。

传统的应用中，Authentication和Authorization都是由应用程序自己进行处理的（即集 成 认证），相对来说问题少一些。只是对于应用开发者来说比较麻烦，每做一个应 用就需要把这一套全实现一次——Copy&Paste也是体力活啊。更麻烦的是对于用户来说，每到一个网站就要把注册流程走一遍，还要碰上用户名 冲突，担心密码安全之类的问题——很多网站对我来说最常用的功能就是：取回密码。囧

集成登录后的权限管理自然也是集成处理。

于是有了单点登录（SSO）——现在这已经是大网站的标配了，都是通过一个passport的统一登录点登录网站下的各个子功能。以及第三方登录——比如现在流行的用twitter或facebook帐号登录（国内对应的是用开心人人之类的帐号登录）。

单点登录后，具体应用取得登录信息，之后的权限管理也是应用程序自己处理，passport应用一般是不管的。

当然，最开放的还是分布式登录，比如OpenID。其实关于OpenID的话题，我早在06年就写过一篇《身份验证——谈谈OpenID》。 现实的发展跟我的预期差不多——OpenID并没有能够得到广泛的应用，最近甚至有消息说，已经有一些网站取消了对OpenID的支持，因为用的人太少 了。目前OpenID协议用得多的话也只是用于第三方登录（相当于单点登录的一种）而不是分布式登录——比如用Google帐号登录其它网站。

这个时候就需要注意Authentication和Authorization的问题了——你一定不希望别人用你的GMAIL帐号给你的朋友发垃圾邮件甚至诈骗邮件吧？如果你是一个第三方应用开发者，你的用户当然也不希望。

以上三种方式的各自优缺点已经在前文里说过了，这里不再讨论。

Authentication 和Authorization两个概念相关性很高，很容易搞混，很多时候这也没什么问题，特别是集成认证的情况下，反正全都在统一控制之下。但是对于第三 方认证的情况下就需要考虑更多一些，最好还是把两种情况分清楚比较好。因此这里主要讨论第三方认证的情况。

第三方认证有很多方式，一般分 为 两类：认证方提供专有的API供认证，比如Microsoft Passport，早年Google也有Account API供Authorization使用（当时并不提供Authentication服务），提供了对日历和通讯录等的授权访问支持；另一类是采用开放方 案，这是目前的主流，最常用的就是OpenID和OAuth。

登录及认证流程

在整个登录认证过程中，可以分成几个参与 方：一个是认证提供方（Provider），另一个是认证使用方（Consumer），介于其中的就是被认证的用户（User）。除此之外，还有一个对 象，那就是服务（Service），即用户登录后所需要使用的功能——这才是用户登录的目的。之所以要单独提到这个Service，是因为它可能是由 Consumer提供，也可能有一部分是由Provider提供。如果Provider完全不提供Service，那Provider就是一个纯粹的 Authentication提供方，如果Provider同时还提供部分Service，比如GOOGLE提供的通讯录、日历等的服务给 Consumer，那么Provider同时还是一个Authorization提供方。

其实通常的分歧也就是出在后一种情况下。因为通常 对于用户的权限管理都是集成在提供Service的Consumer端，登录只是一个Authentication过程，单点登录（SSO）就是一个典型 的情况。只有在第三方登录的情况下才会发生需要认证方提供部分Service，这时才会有部分Authorization工作“外包”的情况。因此导致二 者的混淆与误用。

其实在整个过程中，User的目的只是为了使用Consumer提供的Service，验证身份及权限只是安全性的需要。

在 一个典型的第三方Authentication过程中，User向Consumer请求某个Service，Consumer就向Provider查询 User的身份，User通过密码等方式向Provider验证身份，并允许Provider将验证结果通告Consumer，Consumer在取得 Provider的验证通过结果后，向User提供相应的Service。

而一个典型的第三方Authorization过程中，User 向Consumer请求某个Service时，这个Service可能还需要第三方提供一些辅助的Service，比如通讯录，这时Consumer就要 向Provider请求访问User的这个Service，Provider则向User提示Consumer的这个请求，User通过密码登录 Provider并同意这个请求后，Provider把授权结果返回给Consumer（通常是通过返回一个Token），Consumer这时不但验证 了User的身份，同时还得到了它所需要的User的某些Service访问权限，之后它就可以以这个User的身份访问Provider的相关 Service了。

（上面本来想配两张图的，但是嫌麻烦，懒得画了-_-）

OpenID就是解决前一种场景，而OAuth则是解决后一种情况。

（待续）

推送到[go4pro.org]