apache

0x00 漏洞描述 The REST Plugin is using a XStreamHandler with an instance of XStream for deserialization without any type filtering and this can lead to Remote Code Execution when deserializing XML payloads. -- Apache Struts 官方安全通告(参考1) 2017年9月5日，Apache Struts发布最新安全公告，Apache Struts2的REST插件存在远程代码执行的高危漏洞，该漏洞由lgtm.com的安全研究员汇报，漏洞编号为CVE-2017-9805（S2-052）。Struts2 REST插件的XStream组件存在反序列化漏洞，使用XStream组件对XML格式的数据包进行反序列化操作时，未对数据内容进行有效验证，存在安全隐患，可被远程攻击。 Struts2启用了rest-plugin后并编写并设置了`XStreamHandler`后，可以导致远程命令执行这一严重问题。 0x01 漏洞影响面 1、影响面 确定CVE-2017-9805为高危漏洞。 实际场景中存在一定局限性，需要满足一定条件，非struts本身默认开启的组件。 2、影响版本 Version 2

本文来自 网易云社区 在前一篇我们通过简单几步操作就生成了一个可以直接运行的Web程序，这是因为SpringBoot代替我们做了许多工作，概括来讲可以分为起步依赖和自动配置。这一篇先来看看起步依赖。 项目构建过程解析 前面提到，Spring Boot构建出来的也是一个Maven项目，可以看下自动生成的pom.xml文件： <?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>top.godtm</groupId> <artifactId>blog-demo</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>jar</packaging> <name>blog-demo</name> <description

本文来自 网易云社区 在前一篇我们通过简单几步操作就生成了一个可以直接运行的Web程序，这是因为SpringBoot代替我们做了许多工作，概括来讲可以分为起步依赖和自动配置。这一篇先来看看起步依赖。 项目构建过程解析 前面提到，Spring Boot构建出来的也是一个Maven项目，可以看下自动生成的pom.xml文件： <?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>top.godtm</groupId> <artifactId>blog-demo</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>jar</packaging> <name>blog-demo</name> <description

十一： UDF 函数 自定义函数 之前使用 hive自带函数sum/avg/max/min... 三种自定义函数： UDF：一进一出（User-Defined-Function） UDAF:多进一出 （count、max、min） UDTF:一进多出 （1）导入hive依赖包 hive/lib下。编写自定义函数 （ 2）上传 alt+p （ 3）添加到hive中 add jar /root/lower.jar; (4) 关联（注意是全类名） create temporary function my_lower as "com.itstaredu.com.Lower"; (5) 使用 select ename,my_lower(ename) lowername from empt; 十二： hive 优化 1 ： 压缩 （ 1）开启Map阶段输出压缩 开启输出压缩功能： set hive.exec.compress.intermediate=true; 开启 map输出压缩功能： set mapreduce.map.output.compress=true; 设置压缩方式： set mapreduce.map.output.compress.codec=org.apache.hadoop.io.compres s.SnappyCodec; (2)开启reduce输出端压缩

HTTPClient官网： http://hc.apache.org/httpcomponents-client-4.5.x/quickstart.html 问题一：明明浏览器请求有数据，可使用HTTPClient输出却为空 import org.apache.http.*; import org.apache.http.client.*; import org.apache.http.client.methods.HttpGet; import org.apache.http.impl.client.CloseableHttpClient; import org.apache.http.impl.client.HttpClients; import org.apache.http.util.EntityUtils; import org.junit.Test; @Test public void httpClientTest1() { CloseableHttpClient httpclient = HttpClients.createDefault(); try{ String url = "https://www.80s.tw"; HttpGet httpGet = new HttpGet(url); System.out.println("executing request

前言 最近三周基本处于9-10-6与9-10-7之间，忙碌的节奏机会丢失了自己。除了之前干施工的那段经历，只看参加软件开发以来，前段时间是最繁忙的了。忙的原因，不是要完成的工作量大，而是各种环境问题，各种沟通协调问题。从这个项目，我是体会到了人一多，花在沟通协调上的成本真的会不成比例的放大，制度好，再加上协调好，会极大的提高整体工作效率。怪不得当年华为跟IBM学完工作组织管理制度之后能爆发出如此强劲的战斗力。从另一个角度，也能发觉出为什么大公司招人都比较注重员工的个人实力与团队协作能力，因为如果是多人协作的工作，一旦有人跟不上会极大的拖延整体进度，而且相对而言技术能力强的人更容易沟通交流达成共识，工作协作成本会比能力弱的人低很多。大道千条，我选其一，多提升个人能力才是王道。 闲话少叙，下面继续Dubbo源码的学习。上一节说的是Dubbo用SPI机制来进行Bean的管理与引用，类似于Spring中BeanFactory对bean的管理。SPI实现了类似于 "在容器中管理Bean"的功能，那么问题来了，如果我想在程序运行时调用SPI中管理的类的方法，再通过运行时的参数来确定调用哪个实现类，这么矛盾的场景应该怎么实现？这时就要靠Dubbo的自适应扩展机制了。 正文 实现的思路其实不难，我们先一起来分析一下。首先程序运行时直接调用的SPI管理类中的方法不是通过SPI加载的类

zookeeper是一个高性能,可扩展的服务.zookeeper的读操作 和写操作的设计目标就是速度快,不过zookeeper的读比写快,在读的场景下,zookeeper可以将读的压力分散到不同的follow服务节点上,而且需要读取的数据大部分是已经被更新好了的'旧'的数据,而写操作需要在各个节点间保证一致性同步.保证数据的一致性同步是zookeeper的核心功能,他提供如下保证: 顺序一致性: 从客户端发送过来的命令是按照时间先后顺序有序执行的(注:更新操作是leader节点执行的,读取请求leader/follow都可以执行) 原子性: 更新操作的结果要么成功要么失败,没有部分成功或者部分失败的情况,不会产生部分结果 单一的一致系统映像:客户端读取到数据都是一致的,也就是讲对于一个zookeeper集群来讲,同一时间节点上客户端在任何一个节点读取的数据都是一致的,即使有些特殊情况下zookeeper发生了故障转移,客户端也不会读取到脏的数据 可靠性: 一旦更新被应用了,那么数据就会被持久化了不会被丢失或者篡改除非客户端后面主动的修改这个值,这个保证有2个推论: 如果客户端得到了一个操作的success code,那么这个更新操作就被应用了.一个服务端错误产生了()那么客户端是不知道的操作是成功还是失败了,我们采取的步骤是尽量减少失败,但只有返回成功代码的操作才有保证

Dubbo简介 Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。 下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点： 服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。 配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。 服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。 服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。 集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory