重定向

1.简介 CAS：Yale 大学发起的一个开源项目,旨在为 Web 应用系统提供一种可靠的单点登录方法. Shiro：Apache Shiro是Java的一个安全框架,可以帮助我们完成认证、授权、会话管理、加密等,并且提供与web集成、缓存、rememberMed等功能. * Shiro支持与CAS进行整合使用. 2.CAS Server搭建 参考： https://www.cnblogs.com/funyoung/p/9234947.html 3.CAS Client搭建 3.1 添加Shiro自身以及整合CAS的相关依赖 <dependency> <groupId>org.apache.shiro</groupId> <artifactId>shiro-core</artifactId> <version>1.4.0</version> </dependency> <dependency> <groupId>org.apache.shiro</groupId> <artifactId>shiro-cas</artifactId> <version>1.4.0</version> </dependency> 在web.xml中配置DelegatingFilterProxy并指定targetBeanName. <filter> <filter-name>shiroFilter<

1.简介 SSO (Single Sign On)单点登录 ：在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统. 新浪微博与新浪博客是相互信任的应用系统. * 当用户首次访问新浪微博时,认证中心识别到用户未登录,将请求重定向到登录页. * 当用户已登录再访问新浪博客时,认证中心识别到用户已登录,返回用户的身份,此时用户无需登录即可使用新浪博客. CAS CAS包含CAS Client 和 CAS Server. CAS Client：要使用单点登录的Web应用, 将与同组下的Web应用构成相互信任的关系,只需在web应用中添加CAS提供的Listener和Filter即可成为CAS Client ,其主要负责对客户端的请求进行重定向和校验ticket工作. CAS Server：主要负责对用户的用户名/密码进行认证, 颁发票据等, 需要单独的进行部署. * 同组下的任意一个Web应用登录后其他应用都不需要登录即可使用. 2.CAS服务器搭建 2.1 ȥ CAS官网下载 CAS源码包 将下载的源码包中的cas-server-webapp工程导入ide中,将工程导出为war包,直接放入tomcat下的webapp中运行. * CAS 5.0版本以上需要jdk1.8和gradle进行构建、4.X版本使用maven进行构建(maven 3.3+) 2.2

1.首先了解几个概念　　 1）、TGC：Ticket-granting cookie，存放用户身份认证凭证的cookie，在浏览器和 CAS 2）、TGT：ticket granting ticket，TGT对象的ID就是TGC的值，在服务器端，通过TGC查询TGT。TGT封装了TGC值以及此Cookie值对应的用户信息。 3）、ST：service ticket，CAS为用户签发的访问某一service的票据，ST是TGT签发的。 2.单点登录的流程 现在有系统A、系统B、认证中心。 用户首次访问系统A的时候： 1）用户通过浏览器访问系统A https://localhost:8443/spring-shiro-cas/index，系统A取不到局部session，这时候系统A需要做一个额外的操作，就是重定向到认证中心 2）请求 https://localhost:8443/cas-server/login? service = https://localhost:8443/spring-shiro-cas/cas ,认证中心看浏览器有没有携带TGC，一看没有，返回cas login form让用户登录。 service url（在cas客户端也就是系统A配置） ，将来通过服务端认证后，还要重定向到系统A。/cas是拦截器的地址，接收cas服务端票据

response.sendRedirect()实现重定向（页面跳转） 在某些情况下，针对客户端的请求，一个 Servlet 类可能无法完成全部工作。这时，可以使用请求重定向完成这一工作。 请求重定向指 Web 服务器接收到客户端的请求后，可能由于某些条件的限制，不能访问当前请求 URL 所指向的 Web 资源，而是指定了一个新的资源路径，让客户端重新发送请求。 为了实现请求重定向，HttpServletResponse 接口定义了一个 sendRedirect() 方法，该方法用于生成 302 响应码和 Location 响应头，从而通知客户端重新访问 Location 响应头中指定的 URL，sendRedirect() 方法的完整语法如下所示： public void sendRedirect ( java . lang . String location ) throws java . io . IOException 在上述方法代码中，参数 location 可以使用相对 URL ， Web 服务器会自动将相对 URL 翻译成绝对 URL ，再生成 Location 头字段。 sendRedirect () 方法的工作原理如图 1 所示。 在图 1 中，当客户端访问 Servlet1 时，由于在 Servlet1 中调用了 sendRedirect() 方法将请求重定向到

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/rubulai/article/details/91493686 一、转发 二、重定向 HTTP/1.1 302 Found Location: http://localhost:8080/04_WEB_Servlet/target.html 比较内容 转发 重定向 浏览器发送请求的次数 1 2 发生的位置 服务器 浏览器 地址栏变化 不发生变化 发生改变 浏览器感知 无感知 有感知 //转发 request . getRequestDispatcher ( "login-success.html" ) . forward ( request , response ) ; //重定向 response . sendRedirect ( "login-error.html" ) ; 答：转发和重定向都可以跳转页面，但是转发时浏览器只向服务器发送一次请求，可以使用同一个request携带数据(request的作用域为一次请求)，而重定向时浏览器向服务器发送了两次请求，不可以利用request携带数据，能用重定向的就不要用转发。 文章来源: https://blog.csdn.net/rubulai/article/details/91493686

结论 3XX开头的HTTP状态码都表示重定向的响应。 301、308是永久重定向；302、303、307是临时重定向。 301、302是http 1.0的内容，303、307、308是http1.1的内容。 301和302本来在规范中是不允许重定向时改变请求method的（将POST改为GET），实际许多浏览器实现的时候允许重定向时改变请求method。 303的出现是允许重定向时改变请求method。此外303响应禁止被缓存。307、308则不允许重定向时改变请求method。 RFC 7231规定： 301 Moved Permanently，永久重定向 302 Found 303 See Other 307 Temporary Redirect RFC 7538规定： 308 Permanent Redirect 永久重定向 301、302搜索引擎处理区别 301表示搜索引擎在抓去新内容的同时，将旧的网址替换为重定向之后的网址； 302表示旧地址的资源仍存在，重定向时临时从A地址跳转到B地址，搜索引擎会抓取新的内容，并继续保存旧的网址。 临时重定向：302、303与307 结论 302允许各种各样的重定向，一般都实现为GET到GET重定向，但是不能确保POST会重定向为POST。 303只允许任意请求到GET的重定向。 307和302一样，但不允许POST到GET的重定向。

使用 > 或 >> 时，默认为标准输出 1 重定向, 所以 > file 就是 1> file 的省写，1 与 > 之间不能有空格 。 比如 ls -l > a.txt 就是 ls -l 1> a.txt 数字 0, 1, 2 与它后面的操作符 > 或 < 等 总是一个整体 2>&1 表示把 标准错误输出 重定向到 标准输出, 这在控制台下看到的效果 2>&1 和 1>&2 可能是一样的，因为标准输出或标准错误输出的目的地默认都为屏幕。 2>&1 是最常见到的写，这样就是把错误信息与标准输出都收集到一块了 &> file 表示把 标准输出 和 标准错误输出 都重定向到文件 file 中 >& file 把标准输出和标准错误输出都重定向到文件 file, 由于 > 默认为重定向标准输出，所以和 1>& file 是一个意思 以上 &> file 和 >& file 也较少见，我还不没能理解上边两个中那个光杆子 & 是什么含义 来源： https://www.cnblogs.com/ArChieve/p/11763105.html

第十六章：集成的子框架 django.contrib Python有众多优点，其中之一就是“开机即用”原则： 安装Python的同时会安装好大量的标准软件包，这样 你可以立即使用而不用自己去下载。 Django也遵循这个原则，它同样包含了自己的标准库。 这一章就来讲 这些集成的子框架。 Django标准库 Django的标准库存放在 django.contrib 包中。每个子包都是一个独立的附加功能包。 这些子包一般是互相独立的，不过有些 django.contrib 子包需要依赖其他子包。 在 django.contrib 中对函数的类型并没有强制要求 。其中一些包中带有模型（因此需要你在数据库中安装对应的数据表），但其它一些由独立的中间件及模板标签组成。 django.contrib 开发包共有的特性是: 就算你将整个 django.contrib 开发包删除，你依然可以使用 Django 的基础功能而不会遇到任何问题。 当 Django 开发者向框架增加新功能的时，他们会严格根据这一原则来决定是否把新功能放入 django.contrib 中。 django.contrib 由以下开发包组成： admin : 自动化的站点管理工具。 请查看第6章。 admindocs :为Django admin站点提供自动文档。 本书没有介绍这方面的知识；详情请参阅Django官方文档。

浏览器输入url回车之后做了什么？ （ URL解析 -> DNS查询 -> TCP连接 -> 处理请求 -> 接受响应 -> 渲染页面 ） 1、判断输入的是不是合法的url或关键字 2、浏览器查看缓存（浏览器缓存 -> 系统缓存 -> 路由器缓存），如果有则直接显示内容，没有则走第三步 　　3、发送http之前先域名解析，得到IP 　　4、浏览器想服务器发起TCP连接，建立TCP三次握手 　　5、握手成功后发送http请求，请求数据包 　　6、服务器收到请求会将数据返还给浏览器 　　7、浏览器收到HTTP响应，解码响应 　　8、浏览器请求获取嵌入在html中的资源 　　9、浏览器发送异步请求 　　10、页面全部渲染结束 http协议有哪几种请求方式？ GET, POST ， HEAD，OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。 GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器 POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。 PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。 HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。 DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。

1.redirect和render_template的区别？ redirect：重定向，会改变url render_template：模板渲染，用模板来渲染当前页，不会改变url 来源： https://www.cnblogs.com/remly/p/11755489.html