token

gitlab的用户管理和token的生成

痴心易碎 提交于 2020-01-24 16:35:19
gitlab的用户管理 group分组、 group分组是一种父子目录结构,group下管理project项目, 权限分配一般给group分配权限,下面的project继承proup的权限 gitlab用户权限管理https://blog.csdn.net/qq_37674858/article/details/80825077 官方文档:https://docs.gitlab.com/ee/user/permissions.html gitlab的项目token和用户token gitlab_token是gitlab用户的setting中生成的字符串,使用户可以通过http的形式下载代码 在gitlab用户的setting--access token--填写name+api+read_repository--create personal access token,会生成一个字符串(只出现一次,小心保管) 下载命令: curl -X GET -H "PRIVATE-TOKEN:{{ gitlab_token }}" http://gitlab.sihai.com/api/v4/projects/qp-server%2Fgo_library/repository/archive?sha={{go_library_branch}} -o ./go_library_branch.tar

Getting token start character position relative to the beginning of file

走远了吗. 提交于 2020-01-24 05:44:26
问题 Is there any reliable way with antlr4 API to get Token start character position relative to the beginning of file, not line? After doing some research the only way I found is to use some custom implementation of IntStream, that does not treat '\n' as line terminators, but perhaps I'm missing some easier way? I'm using Visitor API if it matters. The application I'm working on parses source files and provides insertion coordinates for another application that uses provided coordinates to insert

jwt token定时刷新

若如初见. 提交于 2020-01-24 00:31:49
一、token定时刷新的意义 因为登录后获得的token是有时间限制的,也即是有效期,刷新token 一是可以延续token , 二是可以保证安全,即使token被人截获 刷新token后也还是很安全的 。 二、大致实现步骤 在前端登录后的主页 的公共模块或公共组件里面设置一个Interval,也即是 每隔一定周期 去请求后台,通过先前的token得到一个新token,然后前端获取 。 三、代码实现: 1.后台: /** * @Description: 刷新token * @Author: tony * @Date: 2020/1/22 15:40 **/ @RestController @RequestMapping ( "/" ) public class TokenController { private final Logger logger = LoggerFactory . getLogger ( TokenController . class ) ; /** * 刷新用户token * @param request * @return */ @GetMapping ( value = "/refreshToken" ) public R refreshToken ( HttpServletRequest request ) { //这里生成claims

百度AI攻略:名片识别

蓝咒 提交于 2020-01-23 23:23:18
1.功能描述: 支持对各类名片的9个关键字段进行结构化识别,包括姓名、公司、职位、邮编、邮箱、电话、网址、地址、手机号。使用名片识别技术,实现对用户名片关键信息的结构化识别和录入,可应用于线下会议、论坛、商务交流等场景,满足用户快速录入名片关键信息的需求,有效降低用户输入成本,提升用户使用体验。 2.平台接入 具体接入方式比较简单,可以参考我的另一个帖子,这里就不重复了: http://ai.baidu.com/forum/topic/show/943327 3.调用攻略(Python3)及评测 3.1首先认证授权: 在开始调用任何API之前需要先进行认证授权,具体的说明请参考: http://ai.baidu.com/docs#/Auth/top 具体Python3代码如下: # -*- coding: utf-8 -*- #!/usr/bin/env python import urllib import base64 import json #client_id 为官网获取的AK, client_secret 为官网获取的SK client_id =【百度云应用的AK】 client_secret =【百度云应用的SK】 #获取token def get_token(): host = 'https://aip.baidubce.com/oauth/2.0/token

[转帖]3 分钟带你深入了解 Cookie、Session、Token

大憨熊 提交于 2020-01-23 19:32:33
3 分钟带你深入了解 Cookie、Session、Token https://segmentfault.com/a/1190000021543693 经常会有用户咨询,CDN 是否会传递 Cookie 信息,是否会对源站 Session 有影响,Token 的防盗链配置为什么总是配置失败?为此,我们就针对 Cookie、Session 和 Token,来谈谈它们的用处是什么。 Cookie Cookie 虽然听起来不是技术名词,但却为互联网提供一项至关重要的功能:“记录访问过的网站或正在访问的网站。” HTTP 协议是无状态的,服务器不知道浏览器上一次访问做了什么,也无法对用户会话进行跟踪连接。为此就引入 Cookie 技术,Cookie 是由服务器发送到客户端浏览器的一小段文本文件,包含了网站访问活动信息。例如首选项语言或其它一些设置。浏览器会保存这些数据,并在客户端下次访问该网站时调用它们,提供更方便和个性化的访问体验。 举个简单的例子:我们在浏览购物网站时,会将选购商品添加到购物车。如果没有 Cookie 技术,因为 HTTP 是无状态协议,它不会知道之前添加选购哪些商品,放在哪个用户的购物车中。而应用 Cookie 技术后,Cookie 才会将这些信息在会话中发送给服务器,服务器读取 Cookie 信息就知道是哪些用户购物车中添加的商品信息。 Cookie 的属性

Cookie,Session,Token

大兔子大兔子 提交于 2020-01-23 03:54:28
我们知道 HTTP 是一种无状态的协议,为了分辨链接是谁发起的,需自己去解决这个问题。而且一旦数据交换完毕,客户端与服务器端的连接就会关闭,再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。导致有些情况下即使是同一个网站每打开一个页面也都要登录一下。而 Session 和 Cookie 就是为解决这个问题而提出来的两个机制。 同样的 Token 也能解决这个问题,它们之间只是一个说法的差别,其实做的事情都是一样的。 Cookie 实际上是一小段的文本信息是访问某些网站后在本地存储的一些网站相关信息,下次访问时减少一些步骤。更准确的说法是: Cookie 是服务器在本地机器上存储的小段文本信息并随每一个请求发送至同一服务器,是在客户端保持状态的方案。主要包括:名字,值,过期时间,路径和域。路径与域一起构成 Cookie 的作用范围。 会话Cookie和持久Cookie 若不设置过期时间,则表示这个 cookie 的生命期为浏览器会话期间,关闭浏览器窗口, cookie 就消失。这种生命期为浏览器会话期的 cookie 被称为会话 cookie 。会话 cookie 一般不存储在硬盘上而是保存在内存里,当然这种行为并不是规范规定的。若设置了过期时间,浏览器就会把 cookie 保存到硬盘上,关闭后再次打开浏览器,这些 cookie 仍然有效直到超过设定的过期时间

干掉服务状态!从 Session 到 Token,复杂度降低100倍

旧时模样 提交于 2020-01-23 02:34:32
转载:https://mp.weixin.qq.com/s/UzO9Jp79RqGSSMP5GzbVxw 作者:会点代码的大叔 在讲Token之前,先简单说说什么是 Session 和 Cookie。 首先要知道 HTTP 请求是无状态的; 无状态的意思就是:每一次请求都是独立的;每一次请求不会受到前面请求的影响,也不会影响后面的请求; 比如我们登录一个系统的时候,验证用户名密码之后,打开系统各个页面的时候就不需要再进行登录操作了,直到我们主动退出登录或超时退出登录;为了让服务器有“记忆功能”,我们可以用到 Session、Cookie。 1、Cookie 是在客户端(浏览器)保存用户信息的一种机制;Cookie 由服务器生成,发送给浏览器,然后浏览器把 Cookie 以键值对的形式保存在客户端的某个目录下面;每种浏览器存储大小会有一些差异,一般不超过 4KB; 当下一次请求的时候,会把 Cookie 发送给服务端,服务端对 Cookie 中的信息解析并验证身份。 比如你入职一个公司,会给你办一张工卡,上面有你的姓名、工号、部门等信息,你进入职场的时候,拿着工卡就可以进出。 但是 Cookie 是不可以跨域名使用的;就好像我拿着我们公司的工卡,去你们公司,保安肯定是不会放我进去的。 2、Session 保存在服务端,可以用于记录客户状态; 比如我们经常会用 Session

JWT的实现原理

时光毁灭记忆、已成空白 提交于 2020-01-23 02:24:26
前言 最近在做一个python项目的改造,将python项目重构为java项目,过程中遇到了这个知识点,觉得这个蛮实用的,所以下班后回来趁热打铁写下这篇总结,希望后面的人能够有所借鉴,少走弯路。 一、优势简介 JSON Web Tokens简称jwt,是rest接口的一种安全策略。本身有很多的优势: 解决跨域问题:这种基于Token的访问策略可以克服cookies的跨域问题。 服务端无状态可以横向扩展,Token可完成认证,无需存储Session。 系统解耦,Token携带所有的用户信息,无需绑定一个特定的认证方案,只需要知道加密的方法和密钥就可以进行加密解密,有利于解耦。 防止跨站点脚本攻击,没有cookie技术,无需考虑跨站请求的安全问题。 二、原理简介 JSON Web Tokens的格式组成,jwt是一段被base64编码过的字符序列,用点号分隔,一共由三部分组成,头部header,消息体playload和签名sign。 1.jwt的头部Header是json格式: { "typ":"JWT", "alg":"HS256", "exp":1491066992916 } 1 2 3 4 5 6 其中typ是type的简写,代表该类型是JWT类型,加密方式声明是HS256,exp代表当前时间. 2.jwt的消息体Playload { "userid":"123456",

vue+django前后端分析解决csrf token问题

▼魔方 西西 提交于 2020-01-23 02:21:52
vue-resource post数据 参考:https://www.cnblogs.com/linxizhifeng/p/8995077.html 阅读django CsrfViewMiddleware源码可知,csrftoken可以放在请求参数(csrfmiddlewaretoken)里面或者请求头(X-CSRFToken)里: # Check non-cookie token for match. request_csrf_token = "" if request.method == "POST": try: request_csrf_token = request.POST.get('csrfmiddlewaretoken', '') except IOError: # Handle a broken connection before we've completed reading # the POST data. process_view shouldn't raise any # exceptions, so we'll ignore and serve the user a 403 # (assuming they're still listening, which they probably # aren't because of the error).

Django之CSRF

冷暖自知 提交于 2020-01-23 02:20:20
网页向后端传送数据的时候有两种方式,get和post。通过设置form中的method来达到是否采用get或者是post <form action="/show_all/" method="POST"> 但是django中使用post的话会遇到如下的错误 这个错误的意思是csrf校验失败,request请求被丢弃掉。我们先来了解下什么是csrf。 CSRF, Cross Site Request Forgery, 跨站点伪造请求。举例来讲,某个恶意的网站上有一个指向你的网站的链接,如果某个用户已经登录到你的网站上了,那么当这个用户点击这个恶意网站上的那个链接时,就会向你的网站发来一个请求,你的网站会以为这个请求是用户自己发来的,其实呢,这个请求是那个恶意网站伪造 举个例子: 假如用户abc登录了银行的网站,并且向abc2进行了转账,对银行发送的请求是 http://bank.example/withdraw?account=abc&amount=1000000&for=abc2 . 通常情况下,请求发送到服务器后,服务器会首先验证是否是合法的session,如果是则转账成功。假设黑客也有同样银行的账号。他知道转账的时候会生成如上的请求链接。黑客也可以发送同样的请求给服务器要求转账给自己。但是服务器校验他的这个请求不是合法的session。因此黑客想到了CSRF的方式