Web.xml配置详解之context-param

  categories:资料  author:

Web.xml配置详解之context-param
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>contextConfigLocationValue></param-value>
</context-param>
作用:该元素用来声明应用范围(整个WEB项目)内的上下文初始化参数。

param-name 设定上下文的参数名称。必须是唯一名称

param-value 设定的参数名称的值

初始化过程:
在启动Web项目时,容器(比如Tomcat)会读web.xml配置文件中的两个节点<listener>和<contex-param>。
接着容器会创建一个ServletContext(上下文),应用范围内即整个WEB项目都能使用这个上下文。
接着容器会将读取到<context-param>转化为键值对,并交给ServletContext。
容器创建<listener></listener>中的类实例,即创建监听(备注:listener定义的类可以是自定义的类但必须需要继承ServletContextListener)。
在监听的类中会有一个contextInitialized(ServletContextEvent event)初始化方法,在这个方法中可以通过event.getServletContext().getInitParameter(“contextConfigLocation”) 来得到context-param 设定的值。在这个类中还必须有一个contextDestroyed(ServletContextEvent event) 销毁方法.用于关闭应用前释放资源,比如说数据库连接的关闭。
得到这个context-param的值之后,你就可以做一些操作了.注意,这个时候你的WEB项目还没有完全启动完成.这个动作会比所有的Servlet都要早。
由上面的初始化过程可知容器对于web.xml的加载过程是context-param >> listener >> fileter >> servlet

如何使用
页面中
${initParam.contextConfigLocation}

Servlet中
String paramValue=getServletContext().getInitParameter(“contextConfigLocation”)

web.xml文件中配置<context-param>和<init-param>的区别

web工程大多都需要配置web.xml文件,web.xml文件主要用来配置Listener、Filter、Servlet等。web.xml文件包括xml文件头,DOCTYPE声明,web-app元素。

web.xml的加载过程(引用)
在web-app元素内,元素的配置顺序与工程的加载顺序无关,web.xml的加载过程为:

启动一个web项目,web容器(如tomcat)读取web.xml文件,读取其中的配置信息… 阅读全文

访问控制列表(ACL)

  categories:资料  author:

在本章中,我们将会介绍访问控制列表这个复杂话题,它能够提供域对象实例层次授权的丰富模型。Spring Security提供了强大的访问控制列表,但是复杂且缺少文档,它能够很好的满足小到中型规模的实现。
在本章的内容中,我们将会:

理解访问控制列表的概念模型;

了解Spring Security ACL模型中的关于访问控制列表的术语和应用;

构建和了解支持Spring ACL的数据库模式;

配置JBCP Pets通过注解和Spring bean来使用ACL保护业务方法;

进行高级配置,包括自定义许可、使用ACL的JSP标签检查和方法安全,易变的ACL以及缓存;

了解架构要考虑的因素以及规划ACL部署的场景。

译者注:在本章中术语permission翻译为许可权限;entry翻译为条目;access control entry即为访问控制条目。

使用访问控制列表保护业务对象

最后一个非web层安全的问题是业务对象层次的安全,它在业务层或业务层以下。这个层次的安全实现使用了一项名为访问控制列表(access control list,或ACL)的技术。ACL中的对象可以进行权限判断——ACL允许基于唯一的组、业务对象以及逻辑操作进行特定的许可。

例如,在JBCP Pets中的一个ACL声明可能会是这样的:用户只能对自己的简介进行写操作。可能像下面展现的这样:

用户名 对象 许可权限
amy Profile123 read,write
ROLE_USER Profile123 read
ANONYMOUS Any Profile none

你会发现这个ACL对人工来说很易读——Amy对自己的简介(Profile123)能够进行读写;其它的注册用户能够读Amy的简介,而匿名用户不能。简单来说,这种类型的规则矩阵就是ACL所试图做的,即将代码、访问检查、安全系统和业务数据的元数据进行集成。大多数真正使用ACL的系统会有很复杂的ACL列表以及整个系统中百万级的条目。尽管这听起来有令人感到害怕的复杂性,但是预先适当的思考和使用良好的安全库能够使得ACL管理相当可行。

如果你使用Microsoft Windows或者基于Unix/Linux的电脑,那你每天都在体验ACL。大多数现代电脑的操作系统都使用ACL指令作为文件存储系统的一部分,这允许基于用户或组、文件或目录以及许可权限的组合进行许可授权。在Microsoft … 阅读全文

对Acl的支持

  categories:资料  author:

Acl的全称是Access Control List,俗称访问控制列表,是用以控制对象的访问权限的。其主要思想是将某个对象的某种权限授予给某个用户,或某种GrantedAuthority(可以简单的理解为某种角色),它们之间的关系都是多对多。如果某一个对象的某一操作是受保护的,那么在对该对象进行某种操作时就需要有对应的权限。

1.1     准备工作

使用Spring Security的Acl功能需要引入Acl相关的jar包。如果我们的应用是使用Maven构建的,则可以在应用的pom.xml文件中加入如下依赖。

<dependency>

<groupId>org.springframework.security</groupId>

<artifactId>spring-security-acl</artifactId>

<version>${spring.security.version}</version>

</dependency>

此外,使用Spring Security的Acl时需要在数据库中建立四张表。在其官方文档中给出了一个基于数据库HSQLDB的建表语句。其脚本如下:

各个表的简介如下:
users: 不属于ACL的表,用户表,userService会使用本表,users.USERNAME = acl_sid.SID,acl_sid有对应的记录表示同一个principal,所以大家可以看到ER图中没有外键关系
authorities:用于记录用户被授予的权限,authorities.AUTHORITY = acl_sid.SID,acl_sid即可以表示一个principal,也可以表示一个authority,通过acl_sid.PRINCIPAL字段来区分
contacts:是本例的实体表,对该表的记录进行CRWDA权限的控制,contacts.ID = acl_object_identity.OBJECT_ID_IDENTITY;
acl_class: 表示对哪个java entity进行权限控制,本例contacts表只有一条记录为’entity ‘sample.contact.Contact';
acl_sid :security identity,根据PRINCIPAL字段的不同分别表示principal或者authority;
acl_object_identity:acl_object_identity.OBJECT_ID_IDENTITY = contacts.ID,acl_object_identity.OBJECT_ID_CLASS=acl_class.ID
and acl_object_identity.OWNER_SID= acl_sid.ID;分别对对应字段的引用,也就是说id及该entity的类型唯一地确定一条acl_object_identity记录,acl_object_identity是对实体记录的抽象。
acl_entry: acl_entry.SID … 阅读全文

权限鉴定基础

  categories:资料  author:

       Spring Security的权限鉴定是由AccessDecisionManager接口负责的。具体来说是由其中的decide()方法负责,其定义如下。

    void decide(Authentication authentication, Object object, Collection<ConfigAttribute> configAttributes)

        throws AccessDeniedException, InsufficientAuthenticationException;

       如你所见,该方法接收三个参数,第一个参数是包含当前用户信息的Authentication对象;第二个参数表示当前正在请求的受保护的对象,基本上来说是MethodInvocation(使用AOP)、JoinPoint(使用Aspectj)和FilterInvocation(Web请求)三种类型;第三个参数表示与当前正在访问的受保护对象的配置属性,如一个角色列表。

1.1     Spring Security的AOP Advice思想

       对于使用AOP而言,我们可以使用几种不同类型的advice:before、after、throws和around。其中around advice是非常实用的,通过它我们可以控制是否要执行方法、是否要修改方法的返回值,以及是否要抛出异常。Spring Security在对方法调用和Web请求时也是使用的around advice的思想。在方法调用时,可以使用标准的Spring AOP来达到around advice的效果,而在进行Web请求时是通过标准的Filter来达到around advice的效果。

       对于大部分人而言都比较喜欢对Service层的方法调用进行权限控制,因为我们的主要业务逻辑都是在Service层进行实现的。如果你只是想保护Service层的方法,那么使用Spring AOP就可以了。如果你需要直接保护领域对象,那么你可以考虑使用Aspectj。

       你可以选择使用Aspectj或Spring AOP对方法调用进行鉴权,或者选择使用Filter对Web请求进行鉴权。当然,你也可以选择使用这三种方式的任意组合进行鉴权。通常的做法是使用Filter对Web请求进行一个比较粗略的鉴权,辅以使用Spring AOP对Service层的方法进行较细粒度的鉴权。

1.2     AbstractSecurityInterceptor

       AbstractSecurityInterceptor是一个实现了对受保护对象的访问进行拦截的抽象类,其中有几个比较重要的方法。beforeInvocation()方法实现了对访问受保护对象的权限校验,内部用到了AccessDecisionManager和AuthenticationManager;finallyInvocation()方法用于实现受保护对象请求完毕后的一些清理工作,主要是如果在beforeInvocation()中改变了SecurityContext,则在finallyInvocation()中需要将其恢复为原来的SecurityContext,该方法的调用应当包含在子类请求受保护资源时的finally语句块中;afterInvocation()方法实现了对返回结果的处理,在注入了AfterInvocationManager的情况下默认会调用其decide()方法。AbstractSecurityInterceptor只是提供了这几种方法,并且包含了默认实现,具体怎么调用将由子类负责。每一种受保护对象都拥有继承自AbstractSecurityInterceptor的拦截器类, MethodSecurityInterceptor将用于调用受保护的方法,而FilterSecurityInterceptor将用于受保护的Web请求。它们在处理受保护对象的请求时都具有一致的逻辑,具体的逻辑如下。

       1、先将正在请求调用的受保护对象传递给beforeInvocation()方法进行权限鉴定。

       2、权限鉴定失败就直接抛出异常了。

       3、鉴定成功将尝试调用受保护对象,调用完成后,不管是成功调用,还是抛出异常,都将执行finallyInvocation()。

       4、如果在调用受保护对象后没有抛出异常,则调用afterInvocation()。

       以下是MethodSecurityInterceptor在进行方法调用的一段核心代码。

    public Object … 阅读全文

java安全管理器SecurityManager入门

  categories:资料  author:

一、文章的目的

  这是一篇对Java安全管理器入门的文章,目的是简单了解什么是SecurityManager,对管理器进行简单配置,解决简单问题。

比如在阅读源码的时候,发现这样的代码,想了解是做什么的:

SecurityManager security = System.getSecurityManager();
if (security != null) {
    security.checkWrite(name);
}

亦或者在本机运行正常,在服务器运行报错,想解决问题:

SecurityManager在Java中被用来检查应用程序是否能访问一些有限的资源,例如文件、套接字(socket)等等。它可以用在那些具有高安全性要求的应用程序中。通过打开这个功能, 我们的系统资源可以只允许进行安全的操作。

通过查看System.loadLibrary源码

public static void loadLibrary(String libname) {
        Runtime.getRuntime().loadLibrary0(Reflection.getCallerClass(), libname);
    }
 synchronized void loadLibrary0(Class<?> fromClass, String libname) {
        SecurityManager security = System.getSecurityManager();
        
阅读全文

素描速写画人体结构图口诀技巧讲解

  categories:资料  author:

速写是属于素描的一种绘画形式,速写与素描各有特点。它们锻炼人的不同方面的能力。速写:时间较短、表现方式灵活,重在表现人物的动态、精彩的表情、感人的情景或是一瞬即逝的风景。它训练人的观察力、表现力、记忆力、概括力。是一种很好的练习方式。素描:广义的素描包括速写。狭义的素描,指时间较长、表现光影效果、透视和虚实现象、表现物体的结构这样的单色绘画。它训练人的观察力、表现力、对细节的叙述,对画面层次、前后、空间、透视、结构、块面、虚实等都有很精确的要求。速写与素描没有谁高于谁这一说。就像国画与油画一样,是两种不同的表达形式

人物速写,我们最容易出现的问题,就是比例结构找不对,要么头大了,要么手短了,那么今天我们把复杂的人体,简单化来理解,把人体分成具体的几何形,理解掌握好各个几何形之间的间隔比例关系,就能有效的解决人物速写比例结构的问题。

“新七法”中以“比例得当”明确地强调了基础绘画的品评标准。谈到比例,这里应再强调人体的基本结构和动态。如人体的基本比例:即以头为基本单位,按从发际线——下颌——胸线——肚脐之间的距离定为3个头长,还有脐孔到耻骨联合为一个头长。脚底——髌骨——耻骨联合线为4个头长,骨盆线到肚脐还有半个头长。坐五(我们知道,在产生坐姿比例时,上半身基本保持不变,而产生比例变化的地方就在骨盆和髌骨之间)、盘三半(根据人物的动态变化观察比例)。这是画好速写的第二步,这一步强调在平时训练学习过程中,我们必须熟练掌握并了解人体的基本比例。

动态自然 强调动态线

把握控制人体运动规律的两条线:肩线,骨盆线。肩线就是指两个肩点的连线,在人体产生动态变化时,肩线和骨盆线这两条线将会成“倒八字”。我们在充分认识这一规律后,就可以熟练地把握人物运动的基本特点。

比例和动态在速写学习过程中属于重中之重,我们必须熟练地掌握人体结构的基本知识、比例和技能,理解人物骨骼和肌肉的生长规律以及对形体运动所产生美的能量进行明确判断。善于抓住物象的基本特征、注意每个转折部位的扭动关系。

古人习中国画,很注重笔墨。而今,我们研究速写,也如“六法论”里强调“骨法用笔”与“新七法”中强调“轻重适宜”一样,“用线”在表达速写语言里尤为重要,学者应在学习的过程中研究线条的趣味,发现线条的魅力、情趣。“骨法用笔”强调了我们在用线时应该根据物象的形体变化为支撑,善于把握物象的实质,即骨架。速写在用线时也应注意线条的穿插、取舍和提炼,注意线条的对比、变化和节奏(如轻重、虚实、方圆、曲直、疏密、粗细、长短)。流畅的线条可增强画面表现力和生动性,线条的特质与形体结构的巧妙结合,是速写达到“气韵生动”的重要条件。当然,线、面结合的速写更利于增强绘画层次感。

下面和大家将的人体比例结构,是按照七头身的比例进行讲解的。

人体这么多结构,其实数起来一共就17个段,每段之间相互联合结构在一起,就组成了人体

人之所有有各种动态,最主要的是三大固定段与两大活动段的之间相互组合形成的,四肢是丰富动态而存在的。那么三大固定段分别是头,胸腔和髋骨。两大活动段是颈和腰。简称三固定和两活动。

将人体比例结构,肯定要有个标准单位来进行定位,通常我们是以头的长度为单位1对全身各部分进行比较。这里,我们要记住人体简化后的基本型,头为椭圆,胸腔为倒梯形,髋骨为正梯形。这五段的比例如下:

1.头长:1

2.颈(下颚至肩):1/3头

3.胸腔:上下长:一又三分之一头;肩宽两头;腰宽一头

4.腰:上下长1/3头,左右宽1头

5.髋骨:上下长:一头;髋骨上缘:一又三分之一头;下缘一头半

在起大型的过程中,我们其实不妨轻轻的画出这几段,检查上下长度和左右宽度是否正确,目测会有一定难度,建议是拿笔去测量,以保证往下走不会出错。

讲完三固定和两活动,接下来分析手部的结构和比例:

手生根的地方为肩膀,手又分为上臂,前臂和手掌,这三段的比例是:

上臂:一又三分之一头

前臂:一头

手掌:三分之二头

所以手从肩膀至指尖的距离为三头,而三段的比例是4:3:2

这里我要稍微讲一点骨骼,以方便大家理解几本几何形(如下图)

上臂的骨头叫做肱骨,只有一根。前臂的骨头有两根,分别是尺骨和桡骨。手掌的骨头叫手骨。

而手的几本几何形如下,上臂为矩形,因为有肱二头和肱三头肌,所以前后比较宽。前臂类似矩形,但是靠近肘部的地方略宽,之所以上图讲骨骼,前臂有两根骨头,所以导致前臂左右略宽于上臂(如下图)同时还可以注意的是,上臂的长度几本等同于胸腔的长度!

那么想画好手,我们 需要简单了解一下手的肌肉有哪些,

肩头的是三角肌,

三角肌下面,附着于肱骨之上的是肱二头肌(前)和肱三头肌(后),

前臂上的是肱桡肌(大弧线)、尺侧伸腕肌(小弧线)、掌长肌(小弧线)、尺骨(直线)。这里跟大家讲的弧线,看下图就会很明白我在讲什么了:

牢记基本型,记住这几根弧线,就能逐渐画好手!

下半身的大体块有大腿、膝盖、小腿以及骨盆,骨盆往外,大腿往内,膝盖往外,小腿往内,足往外,都是成梯形来回转折的,整个腿的长度从骨盆上缘至足底是四个头,第一个头到腹股沟,第二个投至膝盖中,第三个头至小腿中,第四个头至足底。具体如下图:

以上是正面试图,那么侧面来看,骨盆是向前倾斜的,大腿垂直往下,膝盖也是向前倾斜的,小腿垂直往下,足平置(一头宽),所以如些图,会呈现大腿靠前,小腿靠后的样子

大腿的骨头叫股骨,只有一根,小腿骨头有两根,分别是胫骨和腓骨,这个简单和大家带一下

我们了解了腿部的基本几何形,再来简单了解如何把腿圆起来,请结合文字看图,理解会方便很多,大腿的主要肌肉有三条(股直肌、股内肌、股外肌)所以大腿外侧是一个大弧线,内侧一个中等弧线;膝盖内圆外方;小腿的胫骨是露在外头的,骨头后面是腓肠肌和比目鱼肌,所以小腿外侧也是一个大弧线,内侧是一个小弧线;足和小腿链接的地方有两个关节骨点,注意这个骨点的位置,是内高外低

这里目前不要过多纠结于肌肉和骨骼,只要记住基本几何形和几条弧线,就能够很好地表现结构,多加练习,会越来越熟练,之后再了解一次肌肉和骨骼,就能更深刻的理解,也能更准确地将其形体表达出来。

接下来要讲的,是头、手、足三个部分的比例结构,

首先是头:… 阅读全文

Spring Boot OAuth 2.0 客户端

  categories:资料  author:

在上一篇《OAuth 2.0 授权码请求》中我们已经可以获取到access_token了,本节将使用客户端来访问远程资源

配置资源服务器

授权服务器负责生成并发放访问令牌(access_token),客户端在访问受保护的资源时会带上访问令牌,资源服务器需要解析并验证客户端带的这个访问令牌。

如果你的资源服务器同时也是一个授权服务器(资源服务器和授权服务器在一起),那么资源服务器就不需要考虑令牌解析的事情了,否则这一步是不可或缺的。

To use the access token you need a Resource Server (which can be the same as the Authorization Server). Creating a Resource Server is easy, just add @EnableResourceServer and provide some configuration to allow

阅读全文

OAuth 2.0 授权码请求

  categories:资料  author:

纸上得来终觉浅,绝知此事要躬行。理论知识了解以后,最终还是要动手实践,不亲自做一遍永远不知道里面有多少坑。本节的重点是用Spring Security实现授权码模式。

1. maven依赖

<?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>com.cjs.example</groupId>
    <artifactId>cjs-oauth2-code-server</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>cjs-oauth2-code-server</name>
    <description></description>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.2.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        
阅读全文

Spring Security OAuth2.0

  categories:资料  author:

OAuth 2.0 Provider 实现

在OAuth 2.0中,provider角色事实上是把授权服务和资源服务分开,有时候它们也可能在同一个应用中,用Spring Security OAuth你可以选择把它们分成两个应用,当然多个资源服务可以共享同一个授权服务。

获取token的请求由Spring MVC的控制端点处理,访问受保护的资源由标准的Spring Security请求过滤器处理。

(The requests for the tokens are handled by Spring MVC controller endpoints, and access to protected resources is handled by standard Spring Security request filters. )

为了实现OAuth 2.0授权服务器,在Spring Security的过滤器链中需要有以下端点:… 阅读全文

The OAuth 2.0 Authorization Framework

  categories:资料  author:

OAuth 2.0授权框架支持第三方支持访问有限的HTTP服务,通过在资源所有者和HTTP服务之间进行一个批准交互来代表资源者去访问这些资源,或者通过允许第三方应用程序以自己的名义获取访问权限。

为了方便理解,可以想象OAuth2.0就是在用户资源和第三方应用之间的一个中间层,它把资源和第三方应用隔开,使得第三方应用无法直接访问资源,从而起到保护资源的作用。

为了访问这种受保护的资源,第三方应用(客户端)在访问的时候需要提供凭证。即,需要告诉OAuth2.0你是谁你要做什么。

你可以将用户名和密码告诉第三方应用,让第三方应用直接以你的名义去访问,也可以授权第三方应用去访问。

可以联想一下微信公众平台开发,在微信公众平台开发过程中当我们访问某个页面,页面可能弹出一个提示框应用需要获取我们的个人信息问是否允许,点确认其实就是授权第三方应用获取我们在微信公众平台的个人信息。这里微信网页授权就是使用的OAuth2.0。

1.  Introduction

在传统的client-server认证模型中,客户端通过提供资源所有者的凭证来请求服务器访问一个受限制的资源(受保护的资源)。为了让第三方应用可以访问这些受限制的资源,资源所有者共享他的凭证给第三方应用。

1.1.   Roles

OAuth定义了四种角色:

  • resource owner(资源所有者)
  • resource server(资源服务器)
  • client(客户端):代表资源所有者并且经过所有者授权去访问受保护的资源的应用程序
  • authorization server(授权服务器):在成功验证资源所有者并获得授权后向客户端发出访问令牌

1.2.  Protocol Flow

抽象的OAuth2.0流程如图所示:

  1. (A)  客户端向资源所有者请求其授权
  2. (B)  客户端收到资源所有者的授权许可,这个授权许可是一个代表资源所有者授权的凭据
  3. (C)  客户端向授权服务器请求访问令牌,并出示授权许可
  4. (D)  授权服务器对客户端身份进行认证,并校验授权许可,如果都是有效的,则发放访问令牌
  5. (E)  客户端向资源服务器请求受保护的资源,并出示访问令牌
  6. (F)  资源服务器校验访问令牌,如果令牌有效,则提供服务

1.3.  Authorization Grant

一个授权许可是一个凭据,它代表资源所有者对访问受保护资源的一个授权,是客户端用来获取访问令牌的。

授权类型有四种:authorization … 阅读全文



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