by ·2条评论

在注册完附加服务器后，进行服务器配置的时候，在最后一步出现”You are not authorized to use the server”错误。实际上就是附加服务器没有访问主服务器的权限，同时在主服务器控制台上也出现拒绝访问的消息。

最后查明原因为在服务器文档的安全标签下，”Access Server” 域勾选了”Users listed in all trusted directories”。此选项会只允许信任目录中的用户访问服务器，从而禁止了服务器间的访问。

IBM 的支持网站说可以先取消此复选框，服务器配置完成后，再重新勾上。不过按照我的理解和测试，这样还是会禁止服务器间的访问，应该还是不行的。不知道是不是我理解有误，欢迎大家指教。

相关链接：Server error: “You are not authorized to use the server” setting up a new server

by ·0评论

Dojo 一般的发布包是把各个组件单独存放在各自的文件中的，比如按钮控件对应 /dijit/form/Button.js，这样做对于代码的维护和开发是比较有利的。但如果放在生产环境，每个使用  Dojo 的页面将产生数十个单独的 HTTP 请求，则会影响到应用的性能。针对这个问题，Dojo 提供了一个自定义打包工具，可以将自己常用的组件合并到一个文件中，还能压缩 js、css 文件的大小，以提高性能。

使用此工具需要准备：

  • Java 运行环境
  • Dojo 的源代码包（以 -src 结尾）

接下来是创建 Profile。在 util/buildscripts/profiles 目录下，可以看到一些样例 profile，我们可以参考已有的创建一个：

dependencies ={
    layers:  [
        { //第一部分
        name: "mydojo.js",

dependencies: [ //第二部分
            "dijit.Button",
            "dojox.wire.Wire",
            "dojox.wire.XmlWire",
            "explosive.space.Modulator"
        ]
        }
    ],
    prefixes: [ //第三部分

      [ "dijit", "../dijit" ],
        [ "dojox", "../dojox" ],
        [ "explosive", "../../explosive" ]
    ]
};

下面说明一下各个主要部分的作用：

  1. 指定打包最后生成的文件名
  2. 列举都有哪些组件将被打包到此文件
  3. 各源文件所在的路径，比如 dijit 开头的包，都放在 ../dijit 目录下

然后，运行打包脚本，通过 profile 参数指定配置文件：

$ cd util/buildscripts
$ build.sh profile=foo action=release

最后，将打好包的文件替代原始的 Dojo 文件，加入到页面引用中就行了。

参考资料：The Package System and Custom Builds

by ·0评论

标准的 Dojo 包中提供了很多 Dijit 控件，提供了各种丰富的功能。但是用户需求是多种多样的，总有些标准控件没有实现的部分。还好 Dojo 提供了多种扩展机制，以适应不同的场景。

接下来以为 dijit.Dialog 扩展一个简单的 setTitle 方法为例，介绍一下三种不同的方式。

1、使用 dojo.extend 直接修改 Dialog 的原型

dojo.require("dijit.Dialog");
dojo.extend(dijit.Dialog,{
     setTitle: function(/*string*/title){
         this.titleNode.innerHTML = title || "";
     }
});

2、使用 dojo.mixin 将 setTitle 添加到某个指定的 Dialog 实例

dojo.require("dijit.Dialog");
dojo.addOnLoad(function(){
     var dialog = new dijit.Dialog({ title:"test" });
     dialog.startup();
     dojo.mixin(dialog,{
          setTitle:function(title){
               this.titleNode.innerHTML = title || "";
          }
     });
});

3、使用 dojo.declare 定义一个继承自 Dialog 的子类

dojo.provide("my.Dialog");
dojo.require("dijit.Dialog");
dojo.declare("my.Dialog",dijit.Dialog,{
     setTitle:function(title){
          this.titleNode.innerHTML = title || "";
     }
});

在我的项目中也采用了这种方法，原因如下：一是它保留了原有 Dialog，没有对其进行修改；二是可以通过 inherited 实现往现有的方法中增加代码。例如为 show 方法增加一个判断条件：

dojo.require("dijit.Dialog");
dojo.declare("my.Dialog",dijit.Dialog,{
     canBeShown: true,
     // extend the default show() method
     show:function(){
            if(this.canBeShown){
                    this.inherited(arguments);
            }
     }
});

参考资料：Mucking Dijit

by ·0评论

在与 Domino 做 SSO 的时候，经常会使用 LTPA  的方式，本文描述了它的生成原理，通过它我们可以自己编码生成身份认证的 cookie，实现 SSO。

首先，这个 cookie 由以下部分组成：

  • LTPA token 版本（4字节）
  • 创建时间（8字节）
  • 过期时间（8字节）
  • 用户名（可变长度）
  • Domino LTPA 密钥（20字节）

接下来分别说明各部分的具体内容：

  • LTPA token 版本目前 Domino 只有一种值：0x0001 0x0123
  • 创建时间和过期时间为以十六进制方式表示的 Unix time，例如 2009-04-09 13:52:42 (GMT +8) = 1239256362 = 49DD8D2A。过期时间为 创建时间 + SSO 配置文档的过期时间（LTPA_TokenExpiration域）
  • 用户名为 Names 中用户文档的 FullName 域值
  • Domino LTPA 密钥通过 Base64编码后，保存在 SSO 配置文档的 LTPA_DominoSecret 域中

ltpa-01

在这里当然不能将密钥直接发送给浏览器，所以将上述部分合并起来（如上图），计算 SHA-1 校验和。

ltpa-02

然后用 SHA-1 校验和替换掉 Domino LTPA 密钥，最后再将内容通过 Base64 编码，形成最终的 cookie 发送给浏览器（如上图）。这样如果 cookie 中的任何内容被修改，校验和就不对了，达到了防篡改的效果。

参考资料：Creating a session for a user，The Domino cookie authentication，LTPAUtils

by ·0评论

项目中要将用户输入的文本直接原样显示，所以就想到了 PRE 标签，加上下面的样式，就可以实现自动换行：

word-wrap: break-word;

使用后发现一个问题，如果把 PRE 放在表格中，那么就算内容折行了，但还是会占不换行时的宽度。估计是 IE 的问题，最后找到方法，加入以下样式就没问题了：

white-space : normal;