2010年5月 归档
单点登录和 OpenID
5月31日
上周在石家庄做报告，会后有一个同学对 Single Sign-on 技术非常感兴趣，就在会后进行了交流。
该同学说：
以前没有听说过 SSO, 但是一直有个疑问，为什么不能有一个网站将认证信息统一，其它网站都到那里去登录呢？
听到了 Single Sign-on，觉得这不就是解决方案么？如果谁在公网架设一个 SSO网站，不就实现全网的一次注册了么？
我当时回复他，OpenID是实现全网统一认证的解决方案，而不是单点登录，单点登录可以作为 OpenID 实现的基础。OpenID 推行由于公司政治被破坏。
阅读全部内容 »
Subversion 用户眼中的 Git (13): Git 成为 SVN 的伙伴？
5月30日
很多公司不能代码开源，甚至也不能实现内部的代码开源，这相当大的原因是政治原因，而非技术原因。
那么当工作在 Subversion 的版本库下，是不是就和 Git 绝缘了呢？
非也，答案就是 Git-svn。
Subversion 用户眼中的 Git (12): Git 有属性么？
5月30日
除了在前面比较过的部分检出，路径授权等，还有一些 Subversion 的特性，在 Git 中的实现存在差异。用户最关心的可能就是：属性。
是的，Git 也有属性的概念，但是和 SVN 的属性并非一一对应的。
阅读全部内容 »
群英汇 Mailman 人性化设计(6): 存档安全性
5月30日
Mailman 本身包含两种邮件存档策略：公开的和成员。即或者所有用户均可访问，或者只有订阅者有权访问。当设置为成员访问时，访问列表需要输入密码，而密码是在订阅时输入的，而且可能每月一变，新的密码会发到邮箱中。
我们发现企业用户对邮件列表存档访问的需求有：
- 只允许公司内部人员访问，不允许其它人员访问
- 访问存档的身份认证不要那么复杂，每月一变的密码，让用户访问起来非常不便
于是我们在存档访问时也使用单点登录认证，并在存档访问增加了“认证用户”的新的策略。
即群英汇最新实现的 Mailman 支持三种存档策略：
群英汇在 Mailman 上还有更多的界面上的改进，如 CSS 支持等，不再一一列举。
群英汇 Mailman 人性化设计(5): 创建新列表
5月29日
创建新列表，在 Mailman 中是如何进行的呢？看看 Python 的邮件列表的新建页面。
- 输入列表名称，以及一系列列表的设置
- 在表单的最后，需要输入口令，即：List creator’s (authentication) password
即 Mailman 本身的创建列表的授权，是通过简单的密码检查完成的。这样的实现存在安全问题和管理问题：
- 密码认证在不安全的 http 信道内进行，存在密码泄漏风险
- 只有密码，没有用户名的不完整的认证。知道密码的可能有多个人，无法得知是谁完成的操作
- 密码管理，需要在命令行下执行 mmsitepass 命令重置管理员密码或者列表创建密码
群英汇扩展的Mailman解决这个问题，是通过双因子认证完成的。
阅读全部内容 »
群英汇 Mailman 人性化设计(4): 列表订阅策略
5月27日
Mailman 本身只包含三种订阅策略，有：确认, 要求核准 和 确认并核准。这三种订阅策略都要求用户手工输入自己的邮件地址，以及一个口令。例如：Python-idea 列表的订阅。
这样的邮件列表使用起来不方便，尤其对于企业用户可能有着下面的需求：
- 只允许使用公司内部的邮件地址订阅，不允许使用其它非企业邮箱订阅；
- 如果员工用外网邮箱订阅，会出现员工离职但是邮件通知仍然通过外网邮箱获取，导致信息泄漏；
- 企业都有相应的用户管理中心甚至认证中心，应该允许认证用户直接订阅，而不必手工输入邮件地址信息；
群英汇扩展了邮件列表系统的订阅策略，增加了两个新的订阅策略。
我在 OpenParty 上的报告
5月24日
在参加了北京的OpenParty聚会之后，上周末又赶场式的参加了首届石家庄OpenParty活动。说实话，如此抛头露面前所未有，因为以前一直忙着写代码，眼中看到的一直只是 coding，coding。
石家庄信息工程学院的倪老师是群英汇今年开博后认识的新朋友，禁不住他的一再动员，在半个月前终于下定决心参会。也正是借着倪老师的邮件，使我也发现了北京的OpenParty。上次在北京的OpenParty，我的报告只是停留在一个脑图上，欠了 cleverpig 一个“类PPT”演示文档。这个欠账，终于在上周在为石家庄OpenParty的准备过程中给补上了。
此次石家庄之行，让人印象深刻的除了学院领导老师的热情款待，大大的啤酒的干活，还有石家庄宽宽的城市街道，美丽又宜居的楼房，低的让人眼馋的房价，和谐的行人和机动车（很多斑马线压根没有红绿灯）。石家庄信息工程学院老师们例如倪老师，创造性的将开源融入教学和学生实践之中，更是让人感到振奋，他们真的在做事。这里记录着倪老师他们的教学与参与开源的实践： http://code.google.com/p/teaching-as-community/
我在会议上的报告下载： http://www.ossxp.com/doc/openparty/oss-hacking/ 。其中：
- .odp 格式的是OpenOffice的“类PPT”（超PPT？）格式文档，Windows用户受累到 openoffice.org 上下载最新的 3.2.1 版本并安装
- .pdf 格式，是提供给无法运行 openoffice 的用户的，一些页面的动画效果可能会失去，但不会有太多的影响。
- 没有提供微软的 PPT 格式，因为我不用盗版软件。微软公司的职业诉讼团队还是不要打我们公司的主意了。
TortoiseSVN自动获取redmine问题列表插件—TortoiseSVNRedmineIssuesPlugin
5月20日
众所周知，TortoiseSVN是一款灵活而且功能强大的SVN客户端视图工具。更锦上添花的是，它还提供了整合问题跟踪系统的接口（通过与问题跟踪系统的集成，在提交代码时，可以点击相应的按钮，弹出缺陷跟踪系统中的bug列表，选择相应的bug作为提交日志，即减少了写提交日志的苦恼，又使提交与bug建立的关联，一举两得）。记得以前用Trac做缺陷跟踪管理工具时曾用过trac与TortoiseSVN整合的插件，如今我们的缺陷跟踪工具已经迁移到Remdine上了，不知Redmine是否也有相应的插件？
今天一个很好的客户反映redmine也有相关的插件，可是配置起来出了点问题，希望我们研究一下。于是今天我就在虚拟机里摸索这个插件了。
下面介绍一下安装配置步骤：
阅读全部内容 »
Check — 强大的c语言单元测试框架
5月17日
C 语言的单元测试框架，上 WikiPedia 可以查到很多。经过一番比较之后，选定 check 作为 c 语言的单元测试框架。Check 最主要的优点是对于每一个测试用例的运行都 fork 一个子进程，这么做的原因是因为 C 语言的独特性：
- 其它语言如 Java，Python，Ruby等，单元测试出错最多不过是抛出异常
- C 语言如果指针操作错误，乱指一气，可是会 coredump的。测试框架因此直接退出，用户是看不到任何返回的，只有郁闷的 coredump
- Check 的单元测试运行在 fork 的子进程中，可以避免测试框架由于 coredump 而崩溃，优点显而易见
但是在 Debian 上安装 check，示例代码竟然没有办法编译通过，陷入忙等待，显然是陷入了一个死循环。
Debian 上安装 check，部署了下列文件（只列出主要文件）：
$ dpkg -L check /usr/include/check.h /usr/share/aclocal/check.m4 /usr/share/doc/check/examples/README /usr/share/doc/check/examples/Makefile.am /usr/share/doc/check/examples/configure.ac /usr/share/doc/check/examples/tests/check_money.c /usr/share/doc/check/examples/tests/Makefile.am /usr/share/doc/check/examples/src/money.c /usr/share/doc/check/examples/src/Makefile.am /usr/share/doc/check/examples/src/money.h /usr/share/doc/check/examples/src/main.c ...
将示例拷贝到工作目录，运行，陷入可怕的死循环！ CPU 占用 100%：
$ cp -a /usr/share/doc/check/examples examples $ cd examples $ autoreconf --install -v autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal
我们在运行 autoreconf 时间使用了 -v 参数，看到发生死循环是在运行 aclocal 命令时。怎么办呢？
阅读全部内容 »
Subversion 用户眼中的 Git (11): Git 授权没有 SVN 那样精细
5月17日
的确，Git 的授权做不到 Subversion 那样按照路径进行授权。
Subversion 可以通过授权文件，将权限设置到每一个路径。但是也有缺憾，即权限不能在分支中继承。例如为 /trunk 及其子目录的授权，不能继承到分支或者里程碑中相应的目录下。群英汇通过泛路径授权能够简化分支授权的配置，但毕竟也还是需要进行配置。
Git 的授权模型只能实现非零即壹式的授权，要么拥有全部的写权限，要么没有写权限，要么拥有整个版本库的读权限，要么禁用。
从技术上将，Git 可能永远也做不到类似 SVN 的路径授权（读授权）：
- 如果允许按照路径授权，则各个克隆的关系将不再是平等的关系，有的内容多，有的内容少，分布式的理念被破坏
- 如果只有部分路径可读，则克隆出来的提交和原始提交的提交ID 可能不同。因为提交ID是和提交内容有关的，克隆中提交的部分内容被丢弃，势必提交的 ID 也要重新计算
- 允许全部代码可读，只允许部分代码可写，在版本控制的管理下，是没有多大实际意义的，而且导致了提交的逻辑上的不完整。
那么有什么办法来解决授权的问题么？
- 公司内部代码开放。即代码在公司内部，对项目组成员一视同仁的开放。
就像上周末在北京 OpenParty 上， ThoughtWorks 工程师所说的，虽然我并不是非常认同：公司内部对代码进行精细控制没有意义。代码没什么好隐藏的，有的公司代码拿出去还有害。（因为代码太烂？）
- 公司对代码库进行合理分解，对每个代码库分别授权。即某个代码库对团队成员完全开放，对其它团队完全封闭。
- 公司使用 Subversion 做集中式的版本控制，个人和/或团队，使用 Git-svn。这样在无法改变公司版本控制策略时，程序员采用的变通之法。
- Git 服务器的部署实际上可以使用钩子对 分支和路径进行写授权，即可以控制谁能够创建分支，能够写特定文件。
您有什么更好的建议呢？
最新评论