欢迎您来到 数字平台。 您尚未登录。[登录] [注册新用户]
当前位置: 论坛首页 / 栏目 产品与服务 / 文章 861

点击:5229

[顶层访客留言] [回复顶层(需要先登录)] [表状] [详细]
[回复留言] [回复(需要先登录)] [引用(需要先登录)]普通文章第 1 楼
文章id: 861
关于近期新增功能及对应配置文件调整方法



一、关于禁空密码登录及重置密码的功能配置

         因为当前我们读者数据在读者窗中创建时,默认是空密码,即没有密码。容易被恶意者利用,通过空密码登录进读者环境中,有读者隐私泄漏之虑。

         为了防范空密码的情况,系统可以通过修改dp2OPAC数据目录中的"webui.xml"配置文件,决定是否启用“允许空密码登录”,方法是在"loginControl"元素中,增加一个allowBlankPassword属性,属性值只能二选一:true或者false

         配置效果如下:

         <loginControl allowBlankPassword="false">

 

         在这种情况下,读者只能采用诸如到图书馆工作人员的出纳前端前,常用窗口,修改密码窗,提请工作人员帮其重置密码,或利用系统开通的短信找回密码等方式实现密码重置后正常登录。 

 

         如果想让系统启用短信找回密码的功能,可以在"loginControl"元素中,再增设一个resetPassword属性,属性值也是truefalse二选一,如果设置值为"true",那么,在 login.aspx 的登录面板上,就会出现一个“找回密码”的锚点,点击后,会启用 resetpassword.aspx,这是专门开发的一个 .aspx。如果设置值为"false",就跟以前一样,没有这个功能。

         由于启用这个找回密码功能,还需要在服务器端增加一个dll并作相应的短信帐户设置才能生效,才不至于报错。所以,客户在决定启用这个功能前,需要提前跟公司联系以获得技术支持。

     (短信功能还包括:将预约到书、超期通知等发送到读者手机中去。)

 

         二、关于条码格式服务器校验、允许姓名借书等的功能配置

         之前发现某些客户登记的册条码号、读者证条码号,显然是错误的(比如位数不对、含特殊符号)。究其原因,是因为之前系统比较宽容,认为只要前段提交的册条码号,都可以存贮进数据库中。只不过,在前端可以通过启用条码格式校验函数,实现警示前端工作人员的作用——但这是前端控制,所以工作人员可以通过关闭这种校验功能(或因默认安装内务前端,并没有启用这个前端校验功能),从而把“非法”的条码提交到服务器中。

         有鉴于此,现在通过在服务器端增设一开关参数的方式,允许我们决定是否启用服务器端校验,如果启用,那么,即使前端提交过来的“非法”条码,服务器端也会拒绝。

         启用方式是:

         在图书馆应用服务数据目录中的library.xml配置文件中,增加一个"circulation"元素(如果有,就别增加了),其中有几个属性值,分别对应如下控制:

<circulation verifyBarcode="true" acceptBlankItemBarcode="false" acceptBlankReaderBarcode="false" patronAdditionalFroms="姓名" />

 

verifyBarcode:值为true,即为启用服务器端条码校验;false,则禁用。

acceptBlankItemBarcode:值为true,即允许提交空的册条码号;false,则禁止。

acceptBlankReaderBarcode:值为true,即为提交空的证条码号;false,则禁止。

         从偏严的角度,可以禁止这种空条码号提交到数据库中。但有些应用,比如想提前通过批导入或从第三方接口中采集来的读者数据,没有证条码号信息,留待图书馆工作人员事后补上;又比如某些客户,就是不想在现刊记到时分配册条码号(我不推荐),那么,也得允许他们这种条码号为空的现刊册登记(记到)。所以,可通过这些开关参数由系统管理员根据管理需要灵活控制。

patronAdditionalFroms:值为读者数据中的检索点,可以用英文逗号分隔多个检索点。在这里定义的检索点,都可以参与到出纳装载读者信息的环节中,即如果上面定义了"姓名",那么在借书时,除了扫指纹、证条码号等常规装载读者信息方式外,还允许输入读者姓名实现装载——这是应某客户需求而增加的功能。当然,程序对“重读者姓名”这种情况是作了防范的,届时如果输入的姓名在数据库中比对时遇到重名读者,会弹出一个选择对话框由工作人员选定操作的。但显然,尽量采用比较唯一的检索点作为辅助出纳入口更合理。

 

         三、关于条码格式的客户端验证功能的配置

         一直以来,前端在出纳环节,如果启用了条码验证功能后,都会因为每笔操作,都需要与服务器端配置的条码校验函数作个交互判断。这会增加一点系统响应开销,特别是遇客户端与服务器端网络通讯条件不好时,就会放大出纳操作效率的影响。

         现在可以通过在客户端启用服务器端脚本缓存的方式,将这种校验交互改变为直接在本地与缓存交互方式,从而提高出纳响应效率。

         配置方式为:在服务器端图书馆应用服务数据目录中,cfgs目录中,新增一个client目录,其中新增一个"client.cs"文件,内容为之前服务器端配置的条码校验函数即可(当然,甚至可以让客户缓存的脚本配置跟服务器端的条码校验不一样。)

         服务器端作了如此配置后,内务前端在启动时,就会自动在内务的数据目录中,生成了一个client目录,其中就包含了跟服务器端"client.cs"文件一样内容与名称的文件。以后,客户端出纳操作时,就是按这个本地缓存内容进行条码格式校验与合法性判断了。



发表时间: 2014-01-22 14:02:35
最后修改时间: 2014-01-22 14:23:41
  • 普通文章 关于近期新增功能及对应配置文件调整方法 孤舟蓑笠翁 2014-01-22 14:02:35[点击:5229]
  •  

    在线用户
    访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客
    当前栏目在线用户数 36, 总在线用户数 38