Servlet的Web Fragments和安全性

Web Fragments碎片

  一个web片段是web.xml文件的部分或全部,被包含的库或框架的JAR的 META-INF目录。如果这个框架捆绑在当前项目的WEB-INF/lib目录中, 容器将发现找到并配置框架,而无需开发人员
额外再做任何事情。 它可以包括几乎所有可以在web.xml中指定的元素。配置文件必须是web-fragment.xml. xml.这个名称。

<web-fragment>
<filter>
<filter-name>MyFilter</filter-name>
<filter-class>org.example.MyFilter</filter-class>
<init-param>
<param-name>myInitParam</param-name>
<param-value>...</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>MyFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-fragment>

  开发人员可以指定在web.xml和web-fragment.xml.xml中的资源加载的顺序。在web.xml中<absolute-ordering>元素 用于指定在其中应加载的资源的确切顺序,在web-fragment.xml.xml的<order>也是用于指定相对排序。两个命令是互斥的,而绝对顺序覆盖相对顺序。 绝对顺序包含一个或多个<NAME>元素指定的名称、要加载的资源和顺序。指定<others/>
规定在顺序中没有命名的其他资源加载。

<web-app>
<name>MyApp</name>
<absolute-ordering>
<name>MyServlet</name>
<name>MyFilter</name>
</absolute-ordering>
</web-app>

在web.xml中指定的资源被加载顺序依次是MyServlet和MyFilter。

<before> 和 <after> 可以用在 <ordering>中,指定时间先后:

<web-fragment>
<name>MyFilter</name>
<ordering>
<after>MyServlet</after>
</ordering>
</web-fragment>

指定在MyServlet后面加载资源MyFilter。

如果web.xml 设置 metadata-complete 为true,web-fragment.xml不被处理。

安全性

  Servlet通常通过互联网访问,因此具有安全性要求,使用注释或在web.xml中可以指定servlet的安全模型,包括角色,访问控制 和认证要求。 @ ServletSecurity用于指定的servlet实现安全约束,适合 类的所有方法或特定的doXXX方法。容器将强制由用户指定的角色调用执行 对应的doXXX:

@WebServlet("/account")
@ServletSecurity(
 [email protected](rolesAllowed = {"R1"}),
 httpMethodConstraints={
  @HttpMethodConstraint(value="GET",   rolesAllowed="R2"),
  @HttpMethodConstraint(value="POST",   rolesAllowed={"R3", "R4"})
 }
)
public class AccountServlet extends javax.servlet.http.HttpServlet {
//. . .
}

@ HttpMethodConstraint用于指定该doGet方法可以是属于R2角色的用户访问,doPost方法调用可以由用户是R3和R4角色时被调用。@ HttpConstraint指定所有其他方法可以被
属于角色R1的用户调用。

也可以在web.xml中定义:

<security-constraint>
<web-resource-collection>
<url-pattern>/account/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>manager</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>INTEGRITY</transport-guarantee>
</user-data-constraint>
</security-constraint>

这个部署描述符要求只有在/account/*的URL GET方法 被保护。此方法只能由一个要求内容完整的manager角色的用户访问,所有其他的GET HTTP方法是不受保护。不指定GET等方法,就是指所有方法。

出现在Servlet3.1的新元素<deny-uncovered-http-methods>元素,可以用于拒绝对未覆盖的HTTP方法请求拒绝, 请求返回一个403(SC_FORBIDDEN)状态码:

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<deny-uncovered-http-methods/>
<web-resource-collection>
<url-pattern>/account/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
. . .
</web-app>

该<deny-uncovered-http-methods>元素确保HTTP GET是 调用所需的安全认证,和所有其他的HTTP方法被拒绝返回 一个403状态码。

@RolesAllowed, @DenyAll, @PermitAll, 和 @TransportProtected提供基于代码方法的安全控制访问:

@RolesAllowed("R2")
protected void doGet(HttpServletRequest request, HttpServletResponse response) {
//. . .
}

Serlvet 3.1提供了两个预定义角色:

  1. *映射到任何已定义的角色。
  2. **映射到任何身份验证的用户独立的作用。

@ RolesAllowed,@ DenyAll或@ PermitAll中只能有一个在目标指定。而@TransportProtected注释可能出现的组合是@RolesAllowed 或@ PermitAll注解。

Servlet能被配置成HTTP Basic, HTTP Digest, HTTPS Client, 和 formbased authentication等方式。

<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password" autocomplete="off">
<input type="button" value="submit">
</form>

这段代码显示了如何基于表单的身份验证实现。登录表单必须 包含用于输入用户名和密码字段。这些字段必须命名为 为j_username和j_password。表单的Action总是j_security_check。

Servlet的3.1需要在密码表单字段自动完成设置“关闭”,进一步加强 基于servlet的形式的安全性。
HttpServletRequest的还提供了编程安全与登录,日志 出,并验证方法。
一个校验realm用来验证用户名和密码,配置在ServletContext中。这可确保该容器中的请求的getUserPrincipal,getRemoteUser和getAuthType方法返回一个 有效值。

login方法可以作为一个替代基于表单的登录。为容器配置的登录验证机制将验证这个发出要求登入请求的用户。

时间: 2024-08-27 23:04:01

Servlet的Web Fragments和安全性的相关文章

web iis服务器安全性配置实例

自己不维护服务器,不知道维护服务器的辛苦.刚开始为了嫌麻烦,抱有侥幸心理,一些繁琐的安全设置没有配置,结果服务器连一天都没撑过去.经过10天的反复摸索和努力,现在服务器已经稳定工作一个月了,特此整理本文. 我的服务器的应用含:     APACHE:80     IIS:81,由APACHE映射过来     MySql: 3306     SQLServer2005: 5687     svn: 80     FTP: 21 远程桌面:9898 一:关于TCP/IP筛选      TCP/IP的

Servlet在web.xml中的配置

import javax.servlet.*; import java.io.IOException; import java.io.PipedWriter; import java.io.PrintWriter; /** * Created with IntelliJ IDEA. * User: wbb * Date: 14-6-17 * Time: 上午11:56 * To change this template use File | Settings | File Templates.

servlet 中 web.xml 备忘 总结

<?xml version="1.0" encoding="UTF-8"?><web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.

使用ASP.NET Web Api构建基于REST风格的服务实战系列教程【八】——Web Api的安全性

小分享:我有几张阿里云优惠券,用券购买或者升级阿里云相应产品最多可以优惠五折!领券地址:https://promotion.aliyun.com/ntms/act/ambassador/sharetouser.html?userCode=ohmepe03 系列导航地址http://www.cnblogs.com/fzrain/p/3490137.html 前言 这一篇文章我们主要来探讨一下Web Api的安全性,到目前为止所有的请求都是走的Http协议(http://),因此客户端与服务器之间的

Servlet中Web.xml的配置详解

1 定义头和根元素 部署描述符文件就像所有XML文件一样,必须以一个XML头开始.这个头声明可以使用的XML版本并给出文件的字符编码. DOCYTPE声明必须立即出现在此头之后.这个声明告诉服务器适用的servlet规范的版本(如2.2或2.3)并指定管理此文件其余部分内容的语法的DTD(Document Type Definition,文档类型定义). 所有部署描述符文件的顶层(根)元素为web-app.请注意,XML元素不像HTML,他们是大小写敏感的.因此,web-App和WEB-APP都

servlet和web容器之间的关系

Java是一种动态加载和运行的语言.也就是说当应用程序持有一个类的地址(CLASSPATH)和名称(包名和类名)的情况下,可以在程序运行期 间任何时候加载这个类,并创建和使用该类的对象.Servlet就是基于这个机制与Web容器融合在一起的.目前已知的所有支持Java Servlet的Web容器都是采用Java开发的.当Web容器接收到来自客户端的请求信息之后,会根据URL中的Web元件地址信息到Servlet 队列中查找对应的Servlet对象,如果找到则直接使用,如果没有找到则加载对应的类,

Servlet中Web.xml文件的配置

1 定义头和根元素 部署描述符文件就像所有XML文件一样,必须以一个XML头开始.这个头声明可以使用的XML版本并给出文件的字符编码.DOCYTPE声明必须立即出现在此头之后.这个声明告诉服务器适用的servlet规范的版本(如2.2或2.3)并指定管理此文件其余部分内容的语法的DTD(Document Type Definition,文档类型定义).所有部署描述符文件的顶层(根)元素为web-app.请注意,XML元素不像HTML,他们是大小写敏感的.因此,web-App和WEB-APP都是不

Web 应用的安全性

Web 应用的安全性包括用户认证(Authentication)和用户授权(Authorization)两个部分.用户认证指的是验证某个用户是否为系统中的合法主体,也就是说用户能否访问该系统.用户授权指的是验证某个用户是否有权限执行某个操作.在一个系统中,不同用户所具有的权限是不同的.比如对一个资源来说,有的用户只能进行读取,而有的用户可以进行修改.一般来说,系统会为不同的用户分配不同的角色,而每个角色则对应一系列的权限.

解读Web应用程序安全性问题的本质

转自 http://blog.csdn.net/iwebsecurity/article/details/1688304 相信大家都或多或少的听过关于各种Web应用安全漏洞,诸如:跨site脚本攻击(XSS),SQL注入,上传漏洞...形形色色. 在这里我并不否认各种命名与归类方式,也不评价其命名的合理性与否,我想告诉大家的是,形形色色的安全漏洞中,其实所蕴含安全问题本质往往只有几个. 我个人把Web应用程序安全性本质问题归结以下三个部分: 1.输入/输出验证(Input/output vali