session

前后端分离之JWT用户认证

断了今生、忘了曾经 提交于 2020-02-08 03:32:52
在前后端分离开发时为什么需要用户认证呢?原因是由于HTTP协定是不储存状态的(stateless),这意味着当我们透过帐号密码验证一个使用者时,当下一个request请求时它就把刚刚的资料忘了。于是我们的程序就不知道谁是谁,就要再验证一次。所以为了保证系统安全,我们就需要验证用户否处于登录状态。 传统方式 前后端分离通过Restful API进行数据交互时,如何验证用户的登录信息及权限。在原来的项目中,使用的是最传统也是最简单的方式,前端登录,后端根据用户信息生成一个 token ,并保存这个 token 和对应的用户id到数据库或Session中,接着把 token 传给用户,存入浏览器 cookie,之后浏览器请求带上这个cookie,后端根据这个cookie值来查询用户,验证是否过期。 但这样做问题就很多,如果我们的页面出现了 XSS 漏洞,由于 cookie 可以被 JavaScript 读取,XSS 漏洞会导致用户 token 泄露,而作为后端识别用户的标识,cookie 的泄露意味着用户信息不再安全。尽管我们通过转义输出内容,使用 CDN 等可以尽量避免 XSS 注入,但谁也不能保证在大型的项目中不会出现这个问题。 在设置 cookie 的时候,其实你还可以设置 httpOnly 以及 secure 项。设置 httpOnly 后 cookie 将不能被 JS 读取

Discuz!X1.5 登录机制

流过昼夜 提交于 2020-02-08 03:17:10
最近需要研究一下 Discuz 的整个系统 的架构! 发现Discuz 验证用户是否在线的机制 非常有趣, 这里到时难住了我一个之前没怎么接触过Web系统的,唉,搞了半天才发现,Discuz!X 的判断是否在线的机制,不是跟我们普通想象的在数据库中又一个标志位来标识是否在线。 Discuz在数据库中是没有这个标志位的,只有在pre_common_onlinetime和pre_forum_onlinelist中提到在线相关的,不过pre_common_onlinetime是记录每个用户(UID)在线的总时间的,(据说:这个记录在线总时间的方法就是,每十分钟记录一次在线时间,然后累加在这张表中,不过这个任务我一直没有发现,这个好像是NT版本的 不知道PHP是不是也这样) 还有一张表 pre_forum_onlinelist 用来记录当前在线成员列表的,不过这个列表不是当前在线的成员,而是title Discuz 判断登录是通过Cookie来判断的,我做过实验,如果我把一位已经登录的用户的SID从session表中删除,然后在刷新刚才已经登录的页面,此时这个用户还是在线的状态,从这里可以判断出,不是通过session表中的数据来判断的,当然我也没发现其它的标志是否在线的表。 说明:Discuz 的Cookie 和 server的session 是分开的,相对独立的。

将session存入数据库,memcache的方法

情到浓时终转凉″ 提交于 2020-02-08 03:12:44
//存入数据库 <?php if(!$con = mysql_connect('localhost','root','123456')){ die('连接数据库失败'); } $link = mysql_select_db('session'); //session入库 function open($save_path,$session_name){ return true; } function close(){ } function read($id){ //查询的sql语句 if($result = mysql_query("select * from session where id='{$id}'")){ if($row = mysql_fetch_assoc($result)){ return $row['data']; } }else{ return ''; } } function write($id,$sess_data){ $expire = time(); $query = "insert into session (id,data) values ('{$id}','{$sess_data}') on duplicate key update data = '{$sess_data}'"; if(mysql_query($query)){ return

PHP使用session_set_save_handler陷阱

纵饮孤独 提交于 2020-02-08 02:54:49
陷阱如下 当脚本使用了session_set_save_handler 来重定向 session后,使用session_destroy后再使用session_start()重新开启session会报错 代码如下, <?php function open() { echo 'session start'; echo "\n"; } function close() { echo 'session close'; echo "\n"; } function read($sessionId) { echo 'read'.$sessionId; echo "\n"; } function write($sessionId, $data) { echo 'write'.$sessionId.$data; echo "\n"; } function destroy($sessionId) { echo 'destroy '.$sessionId; echo "\n"; } function gc($lifetime) { echo 'gcccc'; echo "\n"; } session_set_save_handler('open', 'close', 'read', 'write', 'destroy', 'gc'); session_start(); echo session_id()

PHPsession实现用户登陆功能

懵懂的女人 提交于 2020-02-08 02:51:19
对比起 Cookie ,Session 是存储在服务器端的会话,相对安全,并且不像 Cookie 那样有存储长度限制,本文简单介绍 Session 的使用。 由于 Session 是以文本文件形式存储在服务器端的,所以不怕客户端修改 Session 内容。实际上在服务器端的 Session 文件,PHP 自动修改 Session 文件的权限,只保留了系统读和写权限,而且不能通过 ftp 修改,所以安全得多。 对于 Cookie 来说,假设我们要验证用户是否登陆,就必须在 Cookie 中保存用户名和密码(可能是 md5 加密后字符串),并在每次请求页面的时候进行验证。如果用户名和密码存储在数据库,每次都要执行一次数据库查询,给数据库造成多余的负担。因为我们并不能 只做一次验证。为什么呢?因为客户端 Cookie 中的信息是有可能被修改的。假如你存储 $admin 变量来表示用户是否登陆,$admin 为 true 的时候表示登陆,为 false 的时候表示未登录,在第一次通过验证后将 $admin 等于 true 存储在 Cookie,下次就不用验证了,这样对么?错了,假如有人伪造一个值为 true 的 $admin 变量那不是就立即取的了管理权限么?非常的不安全。 而 Session 就不同了,Session 是存储在服务器端的,远程用户没办法修改 Session 文件的内容

PHP全栈学习笔记4

落花浮王杯 提交于 2020-02-08 02:48:05
php和JavaScript,掌握JavaScript基础,自定义函数,流程控制语句,事件,调用JavaScript脚本,在PHP中使用JavaScript。 JavaScript是网景公司开发的,是一种基于对象和事件驱动并具有安全性能的解释型脚本语言。 JavaScript基础,数据类型,变量,注解 数据类型,unll,undefined,对象型,布尔型,数值型,字符串型。 变量,指在程序中已经存在的命名存储单元,存放信息的容器。 abstract, continue, finally, instanceof, private, this class, final, in, package, synchronized, with char, false, import, null, switch, while catch, extends, implements, new, super, void case, else, goto, native, static, var byte, double, function, long, short, true break, do, for, interface, return, typeof boolean, default, float, int, public, throw 自定义函数 function 函数名([参数]){

PHP全栈学习笔记9

对着背影说爱祢 提交于 2020-02-08 02:46:15
php的会话控制,什么是会话控制,http等。 什么是会话控制思想,http协议。 cookie 和 session http是超文本传输协议,是网络上最广泛的一种网络协议。 http最大特点是无连接无状态,clinet到http request到server,server到http response到clinet。 建立一个连接,连接完结束了。 cookie保存在客户端中,内存中的cookie,由浏览器维护,保存在内存中,浏览器关闭后就没了,保存在硬盘中的 cookie,有一个过期时间,除非手动清除和过期时间过了。 cookie使用场景 Cookie:达成服务器和浏览器之间长久连接的状态。 浏览器的cookie以小文件的形式保存在客户端中。 作用:长期登录,购物车。 设置cookie: bool setcookie($name,$value,$expire,$path,$domain,$secure,$httponly); $expire:默认为0s。time() 认识COOKIE? 1.cookie是存储在客户端中的,至于怎么存储,存储的文件是什么这和服务器没有关系,和客户端有关系。 2.COOKIE过期了,也是客户端来判断要不要传递给服务器,如果过期了就删除对应的COOKIE文件。用户也可以手动的清理COOKIE,那么之前保存的COOKIE就全部不见了 3

使用mysql内存表来代替php session的类

人走茶凉 提交于 2020-02-08 02:43:47
<?php /** @Usage: use some other storage method(mysql or memcache) instead of php sessoin @author:lein @Version:1.2 */ session_start(); if(!isset($_SESSION['test'])){ $_SESSION['test']="123_lein_".date("Y-m-d H:i:s"); } class session{ //session data private $data; //engine,mysql or memcache private $engine; //php session expire time private $sessionexpiredTime; //current user's session cookie value private $sessionID; //session coolie name private $sessionCookieName; public function session($engineBase=NULL,$engineName='mysql',$storage_name='php_session'){ try{ $this->sessionexpiredTime =

Codeigniter 利用加密Key(密钥)的对象注入漏洞

房东的猫 提交于 2020-02-08 02:40:59
http://drops.wooyun.org/papers/1449 原文链接:http://www.mehmetince.net/codeigniter-object-injection-vulnerability-via-encryption-key/ 0x00 背景 大家好,Codeigniter 是我最喜爱的PHP框架之一。和别人一样,我在这个框架中学习了PHP MVC编程。今天,我决定来分析一下Codeigniter的PHP 对象注入漏洞。 我在接下来的叙述中会把重点放在Codeigniter的Session会话机制上。所有我将会分析的method方法都在 CodeIgniter/system/libraries/Session.php 文件里。我在本研究过程中使用的是Codeigniter 2.1 版本。 0x01 Codeigniter Session会话机制 Codeigniter 使用PHP的序列化method方法来存储用户Session会话中的变量。但是Codeigniter Session会话机制并不像我们预期的那样工作。它把session会话的变量存在了客户端的cookie里面,大多数是在(服务器)硬盘上而不是用户COOKIE中。我不知道开发者们为什么这么设计。 下面的叙述摘自codeigniter的文档 The Session class stores

Python操作SQLAlchemy之连表操作

心已入冬 提交于 2020-02-08 01:43:17
多对一连表操作 首先有两个知识点: 改变数据输出的方式:可以在表的类中定义一个特殊成员:__repr__,return一个自定义的由字符串拼接的数据连接方式. 数据库中表关系之间除了MySQL中标准的外键(ForeignKey)之外,还可以创建一个虚拟的关系,比如 group = relationship("Group",backref='uuu') ,一般此虚拟关系与foreignkey一起使用. 需求: 用户组,有sa,dba组 用户,用户只能属于一个用户组 那么从需求可以看出来,是一个一对多的 遍历表中数据 接着,我们先来看下数据库中的表结构: from sqlalchemy import create_engine from sqlalchemy.ext.declarative import declarative_base from sqlalchemy import Column, Integer, String, ForeignKey, UniqueConstraint, Index from sqlalchemy.orm import sessionmaker, relationship engine = create_engine("mysql+pymysql://root:7ujm8ik,@192.168.4.193:3306/testsql", max