0%

3.1

  1. 专科上线流程整理,广妇儿1型糖尿病上线准备(上线文档已完成)

  2. 广妇儿满意度–按患者统计卡(已优化,现场更新版本即可)

3.2

  1. 3月份计划目标制定

    • 2.3.2b04–07 4个迭代(陈孝伟、毛子杰)

    • 1型糖尿病广妇儿上线(林剑)

    • 新冠专科专病(吴森、高翔)

    • 专科专病知识库改造(高翔)

    • 专科规则复诊提醒改造(高翔)

    • 邵逸夫专病档案(金翔)

    • 接口(徐贤、张成汉)

3.4

  1. 新冠专科流程讨论(确定改造方案,具体细节产品设计中)

  2. 南京鼓楼专科计划发送表单提交失败(bug,已修复)

  3. 省妇保日间手术手术记录同步问题处理(平台同步数据有延迟)

  4. 厦门医学院附属第二医院字典导入(已完成)

  5. 南京鼓楼随访小结,健康报告上线

3.5

  1. saas环境问题处理

  2. 台州中心院内健康数据没上传问题处理(接口服务启动顺序问题)已处理

  3. 南京鼓楼录音文件占用硬盘高,历史数据备份方案

  4. 省妇保日间手术任务拆分问题(接口未返回手术记录)

  5. 厦门医学院附属第二医院短信接口(已完成)

3.6

  1. 绩效评分

  2. 广妇儿专科上线配合

  3. 南京鼓楼数据库卡,连接数不够用,修改配置扩大连接数

  4. 参加新冠专科会议,明确双方分工,确定双方需提供接口

3.9

  1. 新冠专科宣讲

  2. 云端获取随访记录接口(代码已完成,查询数据时间字段没索引会超时)

3.10

  1. 广妇儿短信平台手动筛选报错问题处理(已处理)

  2. 云端获取随访数据超时解决方案(未找到合理方案)

  3. Mysql线程缓存配置优化

  4. 厦门中山满意度检验、检查来源互斥计划筛选问题(视图字段问题)

  5. 2.3.2b06宣讲

3.11

  1. 港大深圳生殖医学中心需求讨论

    • 方案一:互创系统改造,根据业务场景调用随访接口推送

    • 方案二:随访系统定时抓取数据加,按照不同业务添加到不同患者管理分组

  2. 邵逸夫2.5.0需求、bug处理

  3. 本地模式宣教下载默认不使用317护(已发布)

3.12

  1. 南京鼓楼健康报告、随访小结内网环境查看问题处理

  2. 随访2.5问题处理

  3. 邵逸夫2.5问题处理(需求、bug都已处理)

  4. 厦门大学附属第一医院风湿免疫科方案讨论

    • 嵌入电子病历系统

    • 获取病史、检查、检验等信息,可以人工选择填充内容

    • 评分计算

    • 单个患者历史随访记录

    • 导出所有患者数据

  5. 新冠专科跟进

    • 高翔(动态拆分任务、随访状态更新)

    • 吴森(2推送接口)

3.13

  1. 云端获取随访数据现场医院验证(分页接口有bug,已修复)

  2. 厦门中山二院满意度自动筛选问题(勾选了仅筛选有联系方式的患者,但是号码规则没勾选)

  3. 北京潞河先发微信,后发AI(未处理)

  4. 随访2.5.0问题处理

  5. 表单提交问题(已有补丁包)

  6. Mysql表历史数据转移备份(通过sql脚本将历史数据备份到另一张表,主要问题是:随访有些表没有时间戳,另外如果建的长期的任务,比方说几年,这些任务可能会有影响)

  7. 新冠专科会议

3.14

  1. 新冠专科和5楼对接

    • excel导入模版已提供

    • 修改后的接口文档已提供

  2. 新冠专科提测时间确定(2.18)

  3. ai发送方式优化方案

  4. 生产环境随访后台更新(test-v2.2.9)

跳转iframe postmsg触发

检验数据推送增加F、H、I(接口名称修改)(随访信息)

题目类型增加图片

张静主任,曲院长(瑞金医院院长)牵头

告知书

excel导入量表

如何启动、确定入组人数、上线时间节点

3.15

  1. 南京鼓楼表单发送附加宣教问题排查(手机号没传bug)

  2. 表单数据填充功能整理(发现一个bug和优化点)

  3. 2.3.2b07宣讲

  4. api接口文档软件 – showdoc

3.17

  1. 随访对外接口文档迁移到ShowDoc中 – 金翔

  2. 随访配置文件整理,并维护成文档 – 金翔

  3. 台州中心需求讨论

  4. 厦门第二附属医院录音错误数据删除(已处理)

    1
    2
    3
    4
    5
    DELETE t1, t2, t3
    FROM t_satisfaction_followup_patients t1
    LEFT JOIN t_hospital_followup_record t2 ON t1.id = t2.relation_id
    LEFT JOIN t_manage_call t3 ON t1.id = t3.task_id
    WHERE t1.id = '8aa5eeb2529d46d5962d561d3a9beedc'
  5. 表单提交图片院内看不到(环境未配置)

  6. 发送方式(AI、APP/微信、短信)需求梳理

    • AI发送优先级可选(AI优先、AI补充)

    • 发送方式选了AI,AI发送优先级必选,默认作为补充方式

    • 发送状态

      • 发(微信/短信,发送、回复、异常状态)

      • AI(AI发送、回复、异常状态)

    • AI、短信会产生费用,默认发送方式选择微信,短信、AI不选,发送顺序微信、短信、AI

  7. 专科随访健康档案宣讲

3.18

  1. 南京鼓楼专科随访完成任务修改了计划随访时间bug(浙二个性化需求未复诊患者需要修改随访任务时间,前端未控制好)

  2. 专科随访健康档案梳理(代码分支2.5.0上开发,开发完成人工合并到迭代)

  3. 南京鼓楼发送任务患者未收到(没问题,手动发送有次数限制)

  4. 邵逸夫满意度表单子题选项有重复(历史bug,已修复,但是脏数据需要处理)

  5. 台州中心需求讨论(2个无需处理,2个统计需要个性化开发,统计具体需求待实施明确)

3.19

  1. 专科随访健康档案导入、导出方案构思(邵逸夫提供导入、导出模版)

  2. 随访常见问题维护

  3. 专科随访档案表单改造 – 4天

    • 出生日期(不支持)

    • 生物编号(生成规则)

    • 上一题答案影响下一题目选项范围

    • 表单查看、编辑切换

  4. 丽水中医院宣教院内分配sql(已提供)

  5. 南京鼓楼满意度计划任务加载慢(明天处理,估计是sql效率问题)

  6. 北大深圳图片题院内看不到(bug,已处理)

  7. 现场问题处理机制

    • 实施直接找研发,有些bug已解决会造成重复处理

    • 实施同时找多个研发看同一个问题,白白浪费人力

3.20

  1. 现场问题反馈流程初稿制定

  2. 南京鼓楼满意度计划任务加载慢(动态满意度相关表增加索引)

  3. 部门例会

健海:

  1. 复诊提醒、肺功能检查提醒微信模版推送已修复

  2. 管理后宣教推送未收到。原因:注册绑定流程设计有问题。在健海这边登记之后推送宣教,亿联健还未建立绑定关系,推送的话找不到患者

    亿联健

  3. 微信模版消息推送接口返回有问题(没有收到也返回成功)

  4. 模版消息中的链接打不开

3.23

  1. 鼓楼专科应支持升级至2.5,历史数据随同迁移

    • 南京鼓楼专科随访医生将要管理患者手动添加到患者管理分组中,2.5没有患者管理功能

    • 南京鼓楼的患者还有个性化功能,例如健康报告、随访小结、导出表单记录、导出检验检查等

  2. 广妇儿的个性化、接口的、数据迁移工作量评估下

    • 孕产妇、早发儿童、生殖医学中心自助建档

    • 临床路径随访

    • 患者管理(孕妇根据不同孕周进行分组)

    • 患者档案诊间嵌入

    • 医嘱宣教

    • 表单、宣教发送接口

    • 收案接口

  3. 新冠专科生产环境部署,流程测试

  4. 北京潞河2.5问题处理

3.24

  1. 2.5AI发送成功微信不发送问题 – 高翔

  2. 暨南大学医院网络方案沟通(信息科钟主任)

  3. 投诉表扬第三方嵌入页面PC端适配 – 张琳

  4. 疾病知识库、急救知识库、药品知识库第三方嵌入页面PC端适配 – 张琳

  5. 第三方嵌入投诉表扬页面接口文档编写

  6. 疾病知识库、急救知识库、药品知识库接口文档编写

  7. 现场问题处理流程

3.25

  1. 广妇儿满意度表单提交失败(APP发送bug)– 高翔

  2. 辽中医职工满意度提交成功,院内未收到(数据单独处理)

  3. 随访规范制定并宣讲

3.26

  1. 晨会,分迭代、专项两个小组进行

  2. 2.5项目问题跟进

  3. 中山六院最新就诊状态显示需求和医院沟通

    • 方案一:实时查询。实时性佳,需要新开接口保证效率,无法支持查询。

    • 方案二:定时同步。时效性无法保证,随着随访管理人员的增多需要同步的数据量增大,可以支持查询。

    • 会议议题变更,具体需求为:

      • 一键拨号,提供患者档案嵌入接口

      • 呼入显示,提供号码维护接口

      • 消息推送,提供第三方推送url接口

  4. 2.3.2b09宣讲

  5. 代码规范补充liquisebase模块

3.27

  1. Git commit message规范宣讲

  2. b08 3.30下午验收会,b09 4.2下午验收会,b10 4.2宣讲

  3. 护士转科维护所属科室工作量大(多家医院反馈需求)

    • 和HIS/OA系统对接

      • 职工入职自动开通账号。

      • 职工离职自动注销账号。

      • 职工转科自动修改所属科室。

    • 会有影响的功能

      • 数据查看权限

      • 计划查看权限

      • 任务锁定(各个模块)

      • 计划的移交(各个模块)

      • 满意度处理人

3.28

  1. 护士转科随访系统所属科室自动变更涉及模块、功能继续梳理

  2. 海南现代医院统计sql

  3. 新冠专科新需求讨论

3.30

  1. git hooks

  2. 2.3.2b08验收会

  3. 新冠专科改造方案讨论

3.31

  1. IBD专科验收会

  2. 新冠专科改造讨论

  3. 现场版本更新问题处理

4.1

  1. 新冠专科患者注册流程宣讲、任务拆分

  2. 专科统计宣讲,4.11提测

  3. 邵逸夫满意度发送线程堵塞问题(发送数据量过大,回收控制发送、提交答案都控制导致锁表)

  4. 4月份任务分工

    • 新冠专科 – 吴森、高翔

    • 病程迭代、专科 – 陈孝伟

    • 专科患者档案导入、导出 – 金翔

    • AI辅助 – 高翔

    • 健管功能 – 高翔、金翔

    • 迭代 – 吴森、毛子杰

4.2

  1. 新冠专科医生流程宣讲(为了不影响患者端开发进度,宣讲延后)

  2. 慢病云部署方案评审

  3. 2.3.2b10宣讲

  4. 新冠专科患者端提测

  5. 邵逸夫满意度发送线程堵塞问题跟踪(发送占用资源太多,导致系统卡)

现在手机已经成为了人们必不可少的东西,手机号几乎成了我们身份ID,当前在互联网各大网站、APP等注册几乎都是通过手机号验证短信来完成注册,短信验证码发送一般我们都调用的第三方接口,当然这个是收费的。一般我们在调用第三方短信发送接口时,如果防御没做好,很有可能就成为了黑客攻击的点,可能会在几分钟内就能把你几条短信给耗光,所以做好短信验证码防御是十分重要的,下面我们分享几个方法,本人也是结合了其它网友的方法再加上自己的实践做个完善和补充,希望能帮到需要的人。

(1)单个手机号发送次数限制

比喻每个手机号一天最多只允许收到5条等,这个一般不需要自己在程序里设置,因为一般短信接口商那边可以设置,只需跟客服说一下就可以实现。当然一般黑客攻击其实是用了成千上万个手机号的,重复一个手机号去攻击很少。

(2)发送时间间隔限制

比喻设置60秒或120秒后可再发送,这里注意一点,这个限制要做两面,不仅前端html上对按钮进行失效设置,同时后端也需要验证这个时间限制间隔,只做前端只能防小白。

(3)增加其它字段的验证

在发送手机验证码前,先让用户把如用户名、邮箱、密码等字段填写完整并验证可行性,再允许用户发送手机验证码。

(4)增加图形验证码

图形验证码需要保存在Session里面,并且使用完了一个图形验证码后需立即让这个图形验证码失效,防止黑客一直用一个图形验证码通过。

(5)同一个IP限制发送次数

这里需要开发者先能获取到客户端的真实IP地址,在我的博客上一篇文章《JS和C#.NET获取客户端IP》中有说到如需获取客户端IP的方法。这个限制只能产生一定的限制,作用有限,因为黑客往往都是切换IP的

(6)判断用户发送验证码的页面入口是否是你的注册页面

这一点很重要,黑客在攻击的时候都是直接调用你发送验证的那个中间页面,可能直接跳过了你的注册页面入口,他会按照你的方法拼好要传输的参数字段直接去调用方法,这个时候我只要在后台判断一下用户进来的入口是否是注册页面的地址就行。迫使黑客通过注册页面入口进行入侵,但是这显然加大了攻击的成本。

(7)记录下验证码发送的日志,根据日志分析制定防范方法

如果上面6点做完还是发现攻击存在,那么就需要根据记录下的验证码发送日志分析来制定相应的防范措施了,例如下面就是我截取的一段日志:

这是一段大概3分钟内攻击日志的截图,大家可以看一下手机栏和IP栏,基本IP是一直在换,所以很难去限制,但是仔细分析手机号,发现手机号前6位甚至是前7位重复的概率很高,那么这时候就要对手机号段(前6或前7)来制定防范方案了,根据这些,我这里是做的两点供参考:

a.同一个手机号码段(手机号前6位)120秒内最多发送一次

b.同一个号码段(手机号前6位)当天最多发送10条

c.同一个号码段(手机号前6位)当天发送3次以上且还没有注册的话,不再发送。****

一般情况下,我们只需要做到以上几点基本上可以有效防止短信验证码的攻击。

综上,所谓“道高一尺魔高一丈”,我们很难完全限制住黑客的入侵攻击,我们只能想办法去增加黑客的攻击成本,迫使他们放弃攻击。

大家都知道为了防止我们的网站被有些人和黑客恶意攻击,比如我们网站的注册页面,如果我们在用户注册的时候不加上一个验证码框的话,别人就可以写一个脚本对你的网站进行恶意的注册,比如每分钟对你的网站进行n次的注册,那么你的网站就会被攻击而崩溃。当我们增加了验证码之后,别人再写脚本的时候就必须先识别你的验证码,而要识别图片验证码中的内容,却不是那么的容易,这样就能够有效的防止我们的网站被恶意的注册攻击。废话不多说,直接上代码。

阅读全文 »

scope

scope定义了类包在项目的使用阶段。项目阶段包括: 编译,运行,测试和发布。

scope 描述
compile 默认scope为compile,表示为当前依赖参与项目的编译、测试和运行阶段,属于强依赖。打包之时,会达到包里去。
test 该依赖仅仅参与测试相关的内容,包括测试用例的编译和执行,比如定性的Junit。
runtime 依赖仅参与运行周期中的使用。一般这种类库都是接口与实现相分离的类库,比如JDBC类库,在编译之时仅依赖相关的接口,在具体的运行之时,才需要具体的mysql、oracle等等数据的驱动程序。
此类的驱动都是为runtime的类库。
provided 该依赖在打包过程中,不需要打进去,这个由运行的环境来提供,比如tomcat或者基础类库等等,事实上,该依赖可以参与编译、测试和运行等周期,与compile等同。区别在于打包阶段进行了exclude操作。
system 使用上与provided相同,不同之处在于该依赖不从maven仓库中提取,而是从本地文件系统中提取,其会参照systemPath的属性进行提取依赖。
import 这个是maven2.0.9版本后出的属性,import只能在dependencyManagement的中使用,能解决maven单继承问题,import依赖关系实际上并不参与限制依赖关系的传递性。

type

引入某一个依赖时,必须指定type,这是因为用于匹配dependency引用和dependencyManagement部分的最小信息集实际上是{groupId,artifactId,type,classifier}。在很多情况下,这些依赖关系将引用没有classifier的jar依赖。这允许我们将标识设置为{groupId,artifactId},因为type的默认值是jar,并且默认classifier为null。

type的值一般有jar、war、pom等,声明引入的依赖的类型。

dependency中type默认为jar即引入一个特定的jar包。那么为什么还会有type为pom呢?当我们需要引入很多jar包的时候会导致pom.xml过大,我们可以想到的一种解决方案是定义一个父项目,但是父项目只有一个,也有可能导致父项目的pom.xml文件过大。这个时候我们引进来一个type为pom,意味着我们可以将所有的jar包打包成一个pom,然后我们依赖了pom,即可以下载下来所有依赖的jar包

Dubbo从2.5.3升级到2.7.5

因为Apache Dubbo框架存在远程代码执行高危漏洞,所以需要升级版本到2.7.5,在升级过程中遇到问题,特此记录。

依赖修改

原来依赖为

1
2
3
4
5
<dependency>
<groupId>com.alibaba</groupId>
    <artifactId>dubbo</artifactId>
<version>2.5.3</version>
</dependency>

改为

1
2
3
4
5
<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo</artifactId>
<version>2.7.5</version>
</dependency>

import 包修改

如果有使用dubbo包中的一些工具类:StringUtils、CollectionUtils等,需要修改import包路径

启动报错

1
NoClassDefFoundError: org/apache/curator/RetryPolicy

解决办法

添加依赖

1
2
3
4
5
6
<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-dependencies-zookeeper</artifactId>
    <version>${dubbo.version}</version>
    <type>pom</type>
</dependency>

xml配置修改

原来

1
2
3
4
5
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

改为

1
2
3
4
5
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
xmlns="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">