Cas 4.2.7 OAuth+Rest 实现SSO

  categories:资料  author:

关于Cas的认证原理、Rest的使用请参考前面的文章。本文重点阐述使用Rest接口登陆系统和其他单点登录系统打通遇到的问题,及解决问题的思路和过程。

 一: 遇到的问题
        使用Rest接口实现登陆后,再访问其他使用Cas单点登陆的系统时,Cas认定为当前用户未登陆并要求登陆。经过分析发现,当访问其他使用Cas单点登录系统时Cas无法获取到当前客户端Cookie中的TGC,也就是说使用Rest接口实现登陆Cas无法往客户端Cookie写入TGC。有关TGC的解析这里不详述。
     问题适用场景
  1. 部分系统使用授权免登的方式进入到CAS单点登录系统,同时又希望能使用SSO切换到其他系统。
  2. 部分业务系统有自己的登陆页面,在自己的登陆逻辑中调用Cas的Rest接口实现登陆,同时希望能使用SSO切换到其他系统
二: 解决问题过程
  1. 分析Rest接口发现,调用 cas/v1/tickets/ 接口登陆成功后cas返回了用户的身份信息TGT,那么TGT和TGC有什么关联呢?

收发

 

2. 继续分析cas登陆流程,Cas使用spring-webflow控制登陆流程,找到WEB-INF/webflow/login/login-webflow.xml。在flow执行之前Cas先做了些处理,如下配置

<on-start>
      <evaluate expression="initialFlowSetupAction"/>
</on-start>

追踪到InitialFlowSetupAction类的doExecute方法发现核心代码:

WebUtils.putTicketGrantingTicketInScopes(context,this.ticketGrantingTicketCookieGenerator.retrieveCookieValue(request));

代码说明:当用户访问Cas登陆页时,程序调用this.ticketGrantingTicketCookieGenerator.retrieveCookieValue(request)方法获取TGT并存放入当前作用域中。

         继续追踪到CookieRetrievingCookieGenerator类的retrieveCookieValue方法中:
     try {
            final Cookie cookie = org.springframework.web.util.WebUtils.getCookie(
                    request, getCookieName());
            return cookie == null ? null : 
阅读全文

web.xml的加载过程配置详解

  categories:资料  author:

一:web.xml加载过程

简单说一下,web.xml的加载过程。当我们启动一个WEB项目容器时,容器包括(JBoss,Tomcat等)。首先会去读取web.xml配置文件里的配置,当这一步骤没有出错并且完成之后,项目才能正常的被启动起来。

启动WEB项目的时候,容器首先会去读取web.xml配置文件中的两个节点:<listener> </listener>和<context-param> </context-param>如图:

紧接着,容器创建一个ServletContext(application),这个web项目的所有部分都将共享这个上下文。容器以<context-param></context-param>的name作为键,value作为值,将其转化为键值对,存入ServletContext。

容器创建<listener></listener>中的类实例,根据配置的class类路径<listener-class>来创建监听,在监听中会有初始化方法,启动Web应用时,系统调用Listener的该方法 contextInitialized(ServletContextEvent args),在这个方法中获得:

  ServletContext application =ServletContextEvent.getServletContext();

  context-param的值application.getInitParameter(“context-param的键“);

  得到这个context-param的值之后,你就可以做一些操作了。

  举例:你可能想在项目启动之前就打开数据库,那么这里就可以在<context-param>中设置数据库的连接方式(驱动、url、user、password),在监听类中初始化数据库的连接。这个监听是自己写的一个类,除了初始化方法,它还有销毁方法,用于关闭应用前释放资源。比如:说数据库连接的关闭,此时,调用contextDestroyed(ServletContextEvent args),关闭Web应用时,系统调用Listener的该方法。

  接着,容器会读取阅读全文

Spring Web Flow 2.0 入门详解

  categories:资料  author:

Spring Web Flow (SWF)是Spring Framework的一个脱离模块。这个模块是Spring Web应用开发模块栈的一部分,Spring Web包含Spring MVC。

Spring Web Flow的目标是成为管理Web应用页面流程的最佳方案。当你的应用需要复杂的导航控制,例如向导,在一个比较大的事务过程中去指导用户经过一连串的步骤的时候,SWF将会是一个功能强大的控制器。

Spring Web Flow 是 Spring 的一个子项目,其最主要的目的是解决跨越多个请求的、用户与服务器之间的、有状态交互问题,比较适合任何比较复杂的、有状态的、需要在多个页面之间跳转的业务过程。

配置SWF需要

  • 装配流程执行器(flow executor)

执行器驱动流程的执行,当用户进入流程时,流程执行器会为用户创建并启动一个流程执行实例,当流程暂停的时候(如为用户展示视图时),流程执行器会在用户执行操作后恢复流程。

目录:

  1. 参考文献
  2. 购物车用例
  3. 什么情况下可以使用 Spring Web Flow?
  4. 配置 Spring Web MVC
  5. 配置 Spring Web Flow 2.0 的基础
  6. 在购物车示例应用中配置 Spring
阅读全文

Kubernetes网络接口(CNI) midonet网络插件设计与实现

  categories:资料  author:

先来讲讲什么是CNI?

CNI(容器网络接口)是一种操作容器网络规范,包含方法规范,参数规范等。
CNI只关心容器的网络连接,在容器创建时分配网络资源,并在删除容器时删除分配的资源。因为这个焦点,CNI有广泛的支持,规格易于实现。CNI接口只需要实现两个方法,一个创建容器时调用,一个删除容器时调用。

20170323213331

kubernetes如何支持和运行遵循CNI规范的插件

kubernetes首先以插件的形式完成(pod)容器的网络资源设置。内置的插件包括:cni,kubenet,hostport等。这里简单说说kubenet。这是一个简单的网络插件,每台机器上创建一个br0网桥,根据PodCIDR为每个pod设置ip连接到br0网桥上。次方式可结合一些网络路由工具完成一个小规模的集群网络pod互联。我们主要讲CNI插件。kubernetes以cni插件来支持cni规范,调用其他厂商和个人开发的遵循cni规范的各种网络插件,例如Calico,Flannel等。k8s默认情况下cni模式不支持端口映射等。k8s将容器网络设置none,完全交给插件去管理容器网络资源。
20170323213338

上文多次提到的网络资源是什么?

容器网络资源包括:虚拟网卡,IP地址,DNS,网络路由等等。容器使用独立的网络命名空间,可以具有自己的网络资源信息。这些信息数据由不同的CNI插件根据不同的SDN网络的实现给容器配置。

MidoNet SDN网络

MidoNet是由日本的SDN公司Midkura研发的一款网络虚拟化软件,其基于底层物理设施来实现网络虚拟化,具有分布式、分散、多层次的特点,主要作为OpenStack中的默认网络组件,可以让虚拟网络解决方案,特别是专为网络基础设施设计的方案,为云平台如OpenStack服务,并且将其网络存贮栈虚拟化。MidoNet为每个租户分配一个逻辑router,租户与租户之间是相互隔离的,租户内部之间是能够相互通讯的,Midonet支持L2交换、L3路由、L4负载均衡
有状态和无状态NAT,逻辑和分布式防火墙,BGP与ECMP支持。其架构主要包含以下组件:

Midolman(Midonet Agent):Midonet

Agent安装在各个计算节点,负责建立网络流量控制和提供分布式Midonet网络服务,路由,NAT等他把相关的虚拟网络信息存放到NSDB。

Network State

Database(NSDB):存储网络配置和状态,网络拓扑,路由,Midonet不集中处理网络功能,由Midonet Agent处理,Midonet Agent会跟NSDBs做实时同步当有变化时候会及时同步并且更新NSDB
MidoNet支持大规模SDN集群,其架构理论上支持上万节点。我们可以使用MidoNet完成k8s集群内租户内Pod网络互联。

MidoNet多租户下网络结构模型

SDN(软件定义网络),Midonet软件定义你所熟知的网络组件。以下简单介绍几个核心的软件定义概念:
Router(路由器)
一个租户对应一个Router,连接到同一个Router的Bridge网络互通。Midonet会创建一个PrivierRouter,所有租户Router连接到PrivierRouter与外网互通。等价于一个路由器内网互通,连接上级路由器接入公网。
Bridge(网桥)
一个租户下可以有多个Bridge,每个Bridge使用不同的网段。例如一个Bridge网段为192.168.0.0/24,最多可以有253个虚拟设备连接到本Bridge。
Port(设备通信端口)
Router与Router之间,Router与Bridge之间的通信接口。
Route(路由)
路由规则,给Router定义流量包转发端口的规则。… 阅读全文

速写——衣纹的处理

  categories:儿童画教程  author:

速写——衣纹的处理

牵引线衣褶、堆积型衣褶、折叠型衣褶

知识点一、牵引线衣褶

布本身是没有褶皱的,它是根据外来受力的大小、强弱而产生不同程度的拉伸、转折、堆积称之为衣褶

牵引型衣褶:身体各结构点由于力的作用向两个不同的方向拉扯,布料受力产生褶皱。

1
2

知识点二、堆积型衣褶

堆积型衣褶:一般情况下,堆积形成的衣褶呈螺旋状比现在腰间、撸起的裤腿或袖子等处,画的时候不要因为它看起来很繁琐就感觉难以表现,要主观一些,做出取舍,可以人为地改变他们的形状和大小。

3
5

知识点三、折叠型衣褶

折叠型衣褶:人体在运动时,各体块、关节参与动作时形成的衣褶。这种转折衣褶往往会和牵引型褶皱结合在一起。画好这类衣服褶皱,必须懂得衣服与人体结构的关系。

6

挤压关系:人体周身都可以理解为产生很多转折的圆柱体,衣服附着表面会随着柱体转折而产生挤压褶群,如手肘、膝盖、腰腹、胯及大腿连接处的转折。

7

知识点四、拉伸褶

是指因为力量拉扯出现长的动势褶纹线,起始点必然有骨点支撑。用笔要用中锋转侧锋,快速流畅的画出线条。

8
9

知识点五、挤压褶

因结构转折产生的挤压褶群,通常具有明显的缠绕感,有清晰的主次褶区分。

10

注意以线带面的方式表现对象的素描关系,重点在于理解布褶的形成原理,布褶与形体的关系。关注布褶的时候不能忽略了形体,要做到形与体的的结合。

 

来源: https://baijiahao.baidu.com/s?id=1595911164033903664&wfr=spider&for=pc

阅读全文

手臂肌肉

  categories:儿童画教程  author:

阅读全文

Kafka消费组(consumer group)

  categories:资料  tags:  author:

一直以来都想写一点关于kafka consumer的东西,特别是关于新版consumer的中文资料很少。最近Kafka社区邮件组已经在讨论是否应该正式使用新版本consumer替换老版本,笔者也觉得时机成熟了,于是写下这篇文章讨论并总结一下新版本consumer的些许设计理念,希望能把consumer这点事说清楚,从而对广大使用者有所帮助。

在开始之前,我想花一点时间先来明确一些概念和术语,这会极大地方便我们下面的讨论。另外请原谅这文章有点长,毕竟要讨论的东西很多,虽然已然删除了很多太过细节的东西。

一、 误区澄清与概念明确

1 Kafka的版本

很多人在Kafka中国社区(替群主做个宣传,QQ号:162272557)提问时的开头经常是这样的:“我使用的kafka版本是2.10/2.11, 现在碰到一个奇怪的问题。。。。” 无意冒犯,但这里的2.10/2.11不是kafka的版本,而是编译kafka的Scala版本。Kafka的server端代码是由Scala语言编写的,目前Scala主流的3个版本分别是2.10、2.11和2.12。实际上Kafka现在每个PULL request都已经自动增加了这三个版本的检查。下图是我的一个PULL request,可以看到这个fix会同时使用3个scala版本做编译检查:

目前广泛使用kafka的版本应该是这三个大版本:0.8.x, 0.9.x和0.10.* 。 这三个版本对于consumer和consumer group来说都有很大的变化,我们后面会详谈。

2 新版本 VS 老版本

“我的kafkaoffsetmonitor为什么无法监控到offset了?”——这是我在Kafka中国社区见到最多的问题,没有之一!实际上,Kafka 0.9开始提供了新版本的consumer及consumer group,位移的管理与保存机制发生了很大的变化——新版本consumer默认将不再保存位移到zookeeper中,而目前kafkaoffsetmonitor还没有应对这种变化(虽然已经有很多人在要求他们改了,详见https://github.com/quantifind/KafkaOffsetMonitor/issues/79),所以很有可能是因为你使用了新版本的consumer才无法看到的。关于新旧版本,这里统一说明一下:kafka0.9以前的consumer是使用Scala编写的,包名结构是kafka.consumer.*,分为high-level consumer和low-level consumer两种。我们熟知的ConsumerConnector、ZookeeperConsumerConnector以及SimpleConsumer就是这个版本提供的;自0.9版本开始,Kafka提供了java版本的consumer,包名结构是o.a.k.clients.consumer.*,熟知的类包括KafkaConsumer和ConsumerRecord等。新版本的consumer可以单独部署,不再需要依赖server端的代码。

二、消费者组 (Consumer Group)

1 什么是消费者组

其实对于这些基本概念的普及,网上资料实在太多了。我本不应该再画蛇添足了,但为了本文的完整性,我还是要花一些篇幅来重谈consumer group,至少可以说说我的理解。值得一提的是,由于我们今天基本上只探讨consumer group,对于单独的消费者不做过多讨论。

什么是consumer group? 一言以蔽之,consumer group是kafka提供的可扩展且具有容错性的消费者机制。既然是一个组,那么组内必然可以有多个消费者或消费者实例(consumer instance),它们共享一个公共的ID,即group ID。组内的所有消费者协调在一起来消费订阅主题(subscribed

阅读全文

kafka数据可靠性深度解读

  categories:资料  tags:  author:

1 概述

Kakfa起初是由LinkedIn公司开发的一个分布式的消息系统,后成为Apache的一部分,它使用Scala编写,以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark等都支持与Kafka集成。Kafka凭借着自身的优势,越来越受到互联网企业的青睐,唯品会也采用Kafka作为其内部核心消息引擎之一。Kafka作为一个商业级消息中间件,消息可靠性的重要性可想而知。如何确保消息的精确传输?如何确保消息的准确存储?如何确保消息的正确消费?这些都是需要考虑的问题。本文首先从Kafka的架构着手,先了解下Kafka的基本原理,然后通过对kakfa的存储机制、复制原理、同步原理、可靠性和持久性保证等等一步步对其可靠性进行分析,最后通过benchmark来增强对Kafka高可靠性的认知。

2 Kafka体系架构

如上图所示,一个典型的Kafka体系架构包括若干Producer(可以是服务器日志,业务数据,页面前端产生的page view等等),若干broker(Kafka支持水平扩展,一般broker数量越多,集群吞吐率越高),若干Consumer (Group),以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置,选举leader,以及在consumer group发生变化时进行rebalance。Producer使用push(推)模式将消息发布到broker,Consumer使用pull(拉)模式从broker订阅并消费消息。

名词解释:

2.1 Topic & Partition

一个topic可以认为一个一类消息,每个topic将被分成多个partition,每个partition在存储层面是append log文件。任何发布到此partition的消息都会被追加到log文件的尾部,每条消息在文件中的位置称为offset(偏移量),offset为一个long型的数字,它唯一标记一条消息。每条消息都被append到partition中,是顺序写磁盘,因此效率非常高(经验证,顺序写磁盘效率比随机写内存还要高,这是Kafka高吞吐率的一个很重要的保证)。

每一条消息被发送到broker中,会根据partition规则选择被存储到哪一个partition。如果partition规则设置的合理,所有消息可以均匀分布到不同的partition里,这样就实现了水平扩展。(如果一个topic对应一个文件,那这个文件所在的机器I/O将会成为这个topic的性能瓶颈,而partition解决了这个问题)。在创建topic时可以在$KAFKA_HOME/config/server.properties中指定这个partition的数量(如下所示),当然可以在topic创建之后去修改partition的数量。

 # The default number of log partitions per topic. More partitions allow greater
  1. # parallelism for consumption, but this will also result 
阅读全文

Kafka 设计详解之网络通信

  categories:资料  tags:  author:

前言

Kafka 是 LinkedIn 开发的一个分布式的消息中间件。由于其高吞吐量、可水平扩展等特性,目前被广泛使用,已经是目前大数据生态系统中不可或缺的一环,有关其详细介绍可以查看官方的文档。Kafka 的流行源于他优秀的设计,如依靠磁盘(以及操作系统的 Page Cache)而不是内存来存储队列数据、充分使用零拷贝(zero-copy)以减少数据在不同内存空间间的拷贝、数据尽可能的使用顺序读写等。今天准备深度解析 kafka 的网络通信模块,来学习下实现一个高吞吐量的系统要设计一个怎么样的网络通信机制。

网络通讯协议

作为一个消息队列,涉及的网络通信主要有两块:

  • 消息生产者与消息队列服务器之间(Kafka 中是生产者向队列「推」消息)
  • 消息消费者与消息队列服务器之间(Kafka 中是消费者向队列「拉」消息)

要实现上述的网络通信,我们可以使用 HTTP 协议,比如服务端内嵌一个 jetty 容器,通过 servlet 来实现客户端与服务端之间的交互,但是其性能存在问题,无法满足高吞吐量这个需求。要实现高性能的网络通信,我们可以使用更底层的 TCP 或者 UDP 来实现自己的私有协议,而 UDP 协议是不可靠的传输协议,毕竟我们不希望一条消息在投递或者消费途中丢失了,所以 Kafka 选择 TCP 作为服务间通讯的协议。

网络 IO 模型

谈到网络通信,绕不过 IO 模型,IO 模型主要是同步与异步,阻塞与非阻塞之间进行选择。

阅读全文

Kafka史上最详细原理总结

  categories:资料  tags:  author:

Kafka

Kafka是最初由Linkedin公司开发,是一个分布式、支持分区的(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
1.前言
消息队列的性能好坏,其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度,分析Kafka是如何实现高效文件存储,及实际应用效果。
 1.1  Kafka的特性:
- 高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个topic可以分多个partition, consumer group 对partition进行consume操作。
- 可扩展性:kafka集群支持热扩展
- 持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失
- 容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败)
- 高并发:支持数千个客户端同时读写
1.2   Kafka的使用场景:
- 日志收集:一个公司可以用Kafka可以收集各种服务的log,通过kafka以统一接口服务的方式开放给各种consumer,例如hadoop、Hbase、Solr等。
- 消息系统:解耦和生产者和消费者、缓存消息等。
- 用户活动跟踪:Kafka经常被用来记录web用户或者app用户的各种活动,如浏览网页、搜索、点击等活动,这些活动信息被各个服务器发布到kafka的topic中,然后订阅者通过订阅这些topic来做实时的监控分析,或者装载到hadoop、数据仓库中做离线分析和挖掘。
- 运营指标:Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据,生产各种操作的集中反馈,比如报警和报告。
- 流式处理:比如spark streaming和storm
- 事件源
1.3  Kakfa的设计思想
- Kakfa Broker
阅读全文


快乐成长 每天进步一点点      京ICP备18032580号-1