Flask: SSO原理及实现
博客专区 > 陈亦 的博客 > 博客详情
Flask: SSO原理及实现
陈亦 发表于4年前
Flask: SSO原理及实现
  • 发表于 4年前
  • 阅读 14058
  • 收藏 303
  • 点赞 32
  • 评论 25

腾讯云 学生专属云服务套餐 10元起购>>>   

摘要: 现在大多数软件公司的业务不再是单条线,而是发展成多元化的产品线。包括多个网站应用、移动APP以及桌面软件,那么当然希望能实现统一用户和统一登录。统一用户基本都已实现,然而统一登录却还是有不少公司未予以实现。这倒不是说SSO有多复杂或多难实现,这其中可能有历史遗留问题也或是其它原因。这是题外话,本文不作深究。

现在大多数软件公司的业务不再是单条线,而是发展成多元化的产品线。包括多个网站应用、移动APP以及桌面软件,那么当然希望能实现统一用户和统一登录。统一用户基本都已实现,然而统一登录却还是有不少公司未予以实现。这倒不是说SSO有多复杂或多难实现,这其中可能有历史遗留问题也或是其它原因。这是题外话,本文不作深究。

什么是统一用户

统一用户指的是多个应用共用一套帐号体系。比如Z公司旗下有aw和bw两个网站,有帐号goal,那么使用帐号goal能登录aw和bw。这个在技术上也不难实现,通常来说有2个方案:

  1. 共享持久层

    这是最常用的方式。aw和bw通过直接访问同一个后端数据库来达到数据共享。

  2. 通过代理访问

    这种方式类似于通过网关来访问同一个后端数据库。本质上跟共享持久层是一样的,无外乎多了层网关,这样是有好处的,本文接下来会涉及到。

这看起来好像够了,但是请您考虑这样一个场景:aw和bw是两个不同的网页游戏,那么首先aw和bw都有自己的激活流程,然后有自己的游戏角色、装备等各种属性。所以aw和bw应该有各自的profile。对此我归纳了几下几点:

  1. 统一用户帐号表仅保存各个应用的公共属性,其它应用可以重写这些属性

  2. 应该能标识出是否已激活过

  3. 应该能标识出属于哪个应用

对于第一点,这没什么好说的。第二点和第三点可以分别用一个整型字段来表示,属性存储在不同的位上,而且一般都是这么做的。如下代码所示:

#!/usr/bin/env python
#coding: utf8

#已保存flag,从最低位算起,第一位表示aw,第二位表示bw
app_flag = 0x3
ac_flag  = 0x2

#测试某个应用是否已激活
if ac_flag & 0x1:
	print "aw已激活。"
elif ac_flag & 0x2:
	print "bw已激活。"

#进行激活aw应用
ac_flag |= 0x1

#测试是哪个app
if app_flag & 0x1:
	print "这是aw应用。"
if app_flag & 0x2:
	print "这是bw应用。"

$ python test.py
bw已激活。
这是aw应用。
这是bw应用。

什么是统一登录

统一登录又称SSO(Single Sign On),即单点登录。实现统一登录的前提是已经实现了统一用户。在实现SSO之前的登录流程是这样的:

  1. aw和bw各自维护自己的登录会话

  2. aw的登录不会导致bw登录,相反也是如此

  3. aw的退出不会导致bw的退出,相反也是如此

这种体验对用户来说是极不友好的,明明是同样的帐户,却不得不逐个去输入用户名和密码来登录。SSO正好可以解决这些问题。SSO一般被用于web和web之间,但有时也被用于和桌面软件、移动APP之间的统一登录。不过只有web和web之间才能算是标准的SSO,其它的却不是。接下来分别谈谈这几种方式的原理:

  1. web和web之间单点登录

  2. web和桌面软件、移动APP之间单点登录

web和web之间的单点登录

原理

对于使用session来保存登录态想必各位都没有什么疑问,不明白的可以去自行 Google 。比如有站点aw和bw需要统一登录,那么会出现2种情况:

  1. aw和bw是二级子域名

    例如aw和bw站点域名分别是aw.test.com和bw.test.com,那么其实可以设置session的cookie domain为.test.com来使aw和bw共享会话信息。这种方式不具备通用性并且简单,因此不作深究。

  2. aw和bw都是独立的域名

    因为是2个独立的域名,所以就不能通过设置session的cookie domain来实现了。SSO的做法就是将登录态保存在SSO域(一般也称passort或通行证)上,aw和bw的登录、退出以及授权检查都通过SSO来进行。本文将通篇使用aw, bw和SSO这三个站点来描述,并且使用Python的Flask框架来进行演示,如果没有安装Flask,请先安装。

$ pip install flask

aw和bw是2个不同的web应用,都需要登录才能访问,而SSO就是为aw和bw来提供服务的。为此我配置了3个host,如下图:

调用SSO的方式又可以分为以下2种:

  1. 跳转方式

  2. ajax或jsonp方式

严格意义上来说,ajax和jsonp是属于不同方式。因为ajax没法跨域去调用SSO,它需要通过服务器端代理的方式去调用SSO。而jsonp是可以直接去调用SSO的,当然前提是SSO提供了jsonp方式的访问。这样划分的依据只是为了区分跳转与非跳转。

跳转方式

当用户在aw和bw未登录时,则携带相应参数(如来源网址等)跳转到SSO进行登录,如登录失败则停留在SSO的登录页,登录成功则SSO会生成ticket并附加给来源网址跳转回去。当然SSO在跳转回来源网址时会在SSO域上设置好登录态。既然在SSO上设置登录态,那么在aw和bw上是否需要设置登录态呢?答案是应该设置。举例来说,如果aw跳转到SSO进行登录成功并在SSO上设置好登录态后携带ticket跳转回来,aw需要授权的页面其实都是需要检查用户在aw上是否授权成功,如果不在aw上设置登录态,则始终会跳转到SSO去检测授权,这样的结果就是导致无限循环的跳转,最终导致不可访问。当然还有其它解决方案,那就是通过<script>或<iframe />来实现调用SSO检测,但这是后话,将会在使用ajax或jsonp方式时进行讲解。

如上所述,还是应该在aw和bw上设置各自的登录态,这样在访问aw时首先会在aw域上检测授权,如果没有授权,则跳转到SSO进行登录授权,登录成功之后携带ticket跳转回来。ticket是SSO为此次登录所生成的用户基本信息加密串,来源域可通过解密ticket来获取用户基本信息,从而在来源域中设置登录态。

但是aw和bw应该为登录态设置多长存活期呢?一般设为浏览器进程存活期,也就是说aw和bw的登录态的存活期直到浏览器关闭。SSO域上登录态的存活期取决于具体的业务,本文中设为30天。代码如下:

aw代码:

www/aw

----app.py

#coding: utf8
import os
from datetime import timedelta
from flask import Flask, session, redirect, url_for, request
import urllib

app = Flask(__name__)

app.secret_key = os.urandom(24)
app.permanent_session_lifetime = timedelta(seconds=24 * 60 * 60)

@app.route('/')
def index():
    #表示存活期为浏览器进程的存活期
    session.permanent = False
    ticket = request.args.get('ticket', None)
    if ticket is not None:
        session['name'] = ticket.strip()
    #检测登录态
    if 'name' in session:
        return '登录成功'
    else:
        referer = urllib.quote('http://www.aw.com:6666/')
        return redirect('http://www.sso.com:6668/login?referer=' + referer)

if __name__ == '__main__':
    app.run(
        host="0.0.0.0",
        port=int("6666"),
        debug=True
    )

bw代码:

www/bw

----app.py

#coding: utf8
import os
from datetime import timedelta
from flask import Flask, session, redirect, url_for, request
import urllib

app = Flask(__name__)

app.secret_key = os.urandom(24)
app.permanent_session_lifetime = timedelta(seconds=24 * 60 * 60)

@app.route('/')
def index():
    #表示存活期为浏览器进程的存活期
    session.permanent = False
    ticket = request.args.get('ticket', None)
    if ticket is not None:
        session['name'] = ticket.strip()
    #检测登录态
    if 'name' in session:
        return '登录成功'
    else:
        referer = urllib.quote('http://www.bw.com:6667/')
        return redirect('http://www.sso.com:6668/login?referer=' + referer)

if __name__ == '__main__':
    app.run(
        host="0.0.0.0",
        port=int("6667"),
        debug=True
    )

sso代码:

www/sso

----app.py

----templates

--------login.html

app.py源码:

#coding: utf8
import os
from datetime import timedelta
from flask import Flask, session, render_template, request, redirect
import urllib

app = Flask(__name__)

app.secret_key = os.urandom(24)
app.permanent_session_lifetime = timedelta(seconds=30 * 24 * 60 * 60)

@app.route('/login')
def login():
    session.permanent = True
    referer = request.args.get('referer', None)
    if referer is not None:
        referer = referer.strip()
    if 'name' in session:
        if referer is not None:
            return redirect(referer + '?ticket=' + _makeTicket())
    return render_template('login.html', **dict(referer=referer))

@app.route('/dologin')
def doLogin():
    '''这里其实忽略了判断是否登录的流程'''
    session.permanent = True
    referer = request.args.get('referer', None)
    if referer is not None:
        referer = urllib.unquote(referer.strip())
    #不实现登录功能,直接设置登录态
    _setLoginState()
    if referer:
        return redirect(referer + '?ticket=' + _makeTicket())
    else:
        return 'error'

def _setLoginState():
    session['name'] = 'goal'

def _makeTicket():
    '''生成ticket,这里只是简单返回用户名,真实场景中可以使用des之类的加密算法'''
    return 'goal'

if __name__ == '__main__':
    app.run(
        host="0.0.0.0",
        port=int("6668"),
        debug=True
    )

login.html源码:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>SSO</title>
    <meta name="author" content="" />
    <meta http-equiv="X-UA-Compatible" content="IE=7" />
    <meta name="keywords" content="SSO" />
    <meta name="description" content="SSO" />
</head>
<body>
<a href="{{ url_for('doLogin') }}{% if referer %}?referer={{ referer }}{% endif %}">请登录</a>
</body>
</html>

$ python aw/app.py
 * Running on http://0.0.0.0:6666/
 * Restarting with reloader
$ python bw/app.py
 * Running on http://0.0.0.0:6667/
 * Restarting with reloader
$ python sso/app.py
 * Running on http://0.0.0.0:6668/
 * Restarting with reloader

打开aw站点,发现未登录,则跳转到SSO,点击登录成功后SSO设置登录态并跳转回aw并携带上ticket,aw根据ticket设置登录态。流程对于bw也同样适用。如果关闭浏览器,则aw和bw所设置的登录态失效,但SSO上设置的并未过期,因此重启浏览器打开aw站点将导至跳转到SSO,并且在SSO上授权检测成功,之后再同样设置aw的登录态。

以上是基于跳转的方式实现的SSO,对于退出登录也可以通过同样的方式来实现。

ajax或jsonp方式

对于ajax和jsonp方式来说,这只是请求登录接口的不同方案。因为ajax不能跨域请求,所以需要服务器端代为请求并将结果返回,而jsonp方式是通过<script>标记调用远程脚本来实现的,如果SSO支持jsonp方式,则应优先选用。登录请求过程比较简单,ajax就没什么好说的,因为太常用了。对于jsonp来说,远程执行完毕会返回一段JS代码,通常是返回一个变量的定义,那么我们就可以利用这个变量来拿到ticket并为应用设置登录态。

但是试想下,这种非跳转方式需要跨域设置SSO的登录态,那么这其实是可以通过<script>和<iframe>来实现的。对于IE来说,还需要设置p3p头部,而其它浏览器则不需要设置。在这点上其实是IE遵循了隐私规范,我们不妨为IE点个赞。本文不打算实现ajax和jsonp方式的登录,如果各位有问题,可以一起讨论。

本文将通过<script>的方式对SSO进行跨域设置登录态。很显然,SSO需要提供一个URL调用给应用,并且SSO可以提供一个JS脚本供应用使用,这样就不须各个应用再去实现一遍了。OK,让我们先清除SSO上的会话信息,再重启浏览器。代码如下:

www/aw

----app.py

----templates

--------index.html

app.py源码:

#coding: utf8
import os
from datetime import timedelta
from flask import Flask, session, request, render_template
import urllib

app = Flask(__name__)

app.secret_key = os.urandom(24)
app.permanent_session_lifetime = timedelta(seconds=24 * 60 * 60)

@app.route('/')
def index():
    session.permanent = False
    return render_template('index.html')

if __name__ == '__main__':
    app.run(
        host="0.0.0.0",
        port=int("6666"),
        debug=True
    )

index.html源码:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>aw</title>
    <meta name="author" content="" />
    <meta http-equiv="X-UA-Compatible" content="IE=7" />
    <meta name="keywords" content="aw" />
    <meta name="description" content="aw" />
    <script type="text/javascript" src="http://cdn.staticfile.org/jquery/2.1.0/jquery.min.js"></script>
    <script type="text/javascript" src="http://www.sso.com:6668/static/sso.js"></script>
</head>
<body>
</body>
</html>

www/sso

----app.py

----static

--------sso.js

app.py源码:

#coding: utf8
import os
from datetime import timedelta
from flask import Flask, session, request, make_response
import urllib

app = Flask(__name__)

app.secret_key = os.urandom(24)
app.permanent_session_lifetime = timedelta(seconds=30 * 24 * 60 * 60)

@app.route('/setLoginState')
def setLoginState():
    session.permanent = True
    session['name'] = 'goal'
    session['nick'] = '陈一回'
    resp = make_response('')
    resp.headers['P3P'] = 'CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"'
    return resp

@app.route('/test')
def test():
    session.permanent = True
    _str = ''
    if 'name' in session:
        _str = session['name']
    if 'nick' in session:
        _str += '---' + session['nick']
    return _str

if __name__ == '__main__':
    app.run(
        host="0.0.0.0",
        port=int("6668"),
        debug=True
    )

sso.js源码:

$(function() {
	$.getScript("http://www.sso.com:6668/setLoginState", function() {
		console.log('success.');
	});
});

$ python aw/app.py
 * Running on http://0.0.0.0:6666/
 * Restarting with reloader
$ python sso/app.py
 * Running on http://0.0.0.0:6668/
 * Restarting with reloader

通过访问 http://www.aw.com:6666  来设置SSO的登录态,之后可以通过 http://www.sso.com:6668/test  来查看输出,结果很明显是设置成功的。关于非跳转方式的授权检测以及退出登录也是大同小异的,明白了原理,实现起来就很简单了。

统一退出

统一退出的概念即是任何一方应用退出登录,在清除应用自身的登录态时也清除SSO的登录态。这看起来没有什么问题,举个例来说,aw和bw都登录过,也就说aw、bw和SSO都设置过登录态。aw的退出将会清除aw和SSO的登录态,但bw还在会话期内,除非浏览器被关闭,否则bw还是会处于登录状态的。解决方案也是有的,在aw退出时,顺便也清除bw的登录态(可通过远程URL调用和P3P结合的方式来实现)。但如果SSO关联的应用非常多,那么退出的过程也变得漫长。有些公司的网站甚至是通过跳转方式来进行逐一清除登录态,这个没有完美的解决方案,关键在于取舍。

统一授权检测

之前所述的aw和bw本身也会设置登录态。如果不想设置登录态,则可以通过SSO实现JS API供aw和bw来调用,在每个页面中通过远程URL调用SSO的授权检测。但这样很明显是弊大于利,不仅会令SSO的请求数呈指数级增长,并且增加了aw和bw的编码难度。

强制退出

考虑这么一种场景。基于同一个用户,在A电脑上登录了aw,之后没有关闭浏览器,然后在B电脑上也登录了aw。那么能否强制A电脑上的用户退出呢?这个退出分为SSO的退出和aw的退出。令SSO的退出是可以实现的,只要在登录态中保存登录时间戳,服务器端持有用户标识到登录态的映射,那么B电脑上的登录会令登录态和服务器端的映射同步,而A电脑上的登录态将会过期。这个时候如果在A电脑上开启bw(之前未登录),则会跳转到SSO,很明显,这个时候A电脑上的SSO将是未授权状态。对于A电脑上的aw,并没有办法去清除它的登录态。

UserAgent

之前一直忽略了一个事实,所谓共享SSO登录态,其实是基于同一个UserAgent的。对于web应用来说,UserAgent就是浏览器。这是因为浏览器之间无法共享cookie,而session是基于cookie的。

web和桌面软件、移动APP之间单点登录

这个其实不能算严格意义上的SSO,只能算是代签。可以登录2个QQ号来进行观察,登录后在2个QQ上点击邮箱图标进入邮箱,您可以发现链接上被附加了一串sid。sid是session id的缩写,可以用来标识一个会话。您可以清楚的看到邮箱上的每个链接都被附加上了一串sid参数,这是因为允许同时使用多个邮箱,如果设置登录态的话则会覆盖前一个。这种方式看起来就像早期PHP不支持session的做法,每次通过传递sid到服务器端来解密进行标识用户。

对于移动APP的授权,有使用OAuth方式,也有使用传递sid方式,对此不作深究。

SSO可以同时支持传递sid、OAuth方式和登录态方式的授权校验,并只能被授权后的应用使用SSO。

标签: Python Flask SSO passport
共有 人打赏支持
粉丝 221
博文 23
码字总数 53194
评论 (25)
光石头
统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796
陈亦

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0
光石头

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口
陈亦

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?
光石头

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户
陈亦

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?
光石头

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.
陈亦

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.

这难道不是本文所说的P3P的退出方式?那么你觉得aw和bw要不要提供接口呢?至于SSO要不要和应用分离,这是业务决定的。方案本文都已经说过了,P3P方式逐个清除登录态或逐个跳转方式清除登录态。SSO关联的应用一多,弊端立显。这又岂能称之为完美解决方案?像你所说的限制应用场景而称之的方案就更不能算了。
光石头

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.

这难道不是本文所说的P3P的退出方式?那么你觉得aw和bw要不要提供接口呢?至于SSO要不要和应用分离,这是业务决定的。方案本文都已经说过了,P3P方式逐个清除登录态或逐个跳转方式清除登录态。SSO关联的应用一多,弊端立显。这又岂能称之为完美解决方案?像你所说的限制应用场景而称之的方案就更不能算了。

不针对应用是针对域名 只有不同域名下的才会逐个清除,而且是写一个功能的页面.我是不考虑多少应用,只考虑多少域名.我的也没有限制使用场景
陈亦

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.

这难道不是本文所说的P3P的退出方式?那么你觉得aw和bw要不要提供接口呢?至于SSO要不要和应用分离,这是业务决定的。方案本文都已经说过了,P3P方式逐个清除登录态或逐个跳转方式清除登录态。SSO关联的应用一多,弊端立显。这又岂能称之为完美解决方案?像你所说的限制应用场景而称之的方案就更不能算了。

不针对应用是针对域名 只有不同域名下的才会逐个清除,而且是写一个功能的页面.我是不考虑多少应用,只考虑多少域名.我的也没有限制使用场景

应用和域名那只是实现的细节。你可以认为本文所说的每个应用都是一个独立的域名。
光石头

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.

这难道不是本文所说的P3P的退出方式?那么你觉得aw和bw要不要提供接口呢?至于SSO要不要和应用分离,这是业务决定的。方案本文都已经说过了,P3P方式逐个清除登录态或逐个跳转方式清除登录态。SSO关联的应用一多,弊端立显。这又岂能称之为完美解决方案?像你所说的限制应用场景而称之的方案就更不能算了。

不针对应用是针对域名 只有不同域名下的才会逐个清除,而且是写一个功能的页面.我是不考虑多少应用,只考虑多少域名.我的也没有限制使用场景

应用和域名那只是实现的细节。你可以认为本文所说的每个应用都是一个独立的域名。

还是这两个:不建议sso和应用分离,不建议后台提权.sso和应用分离就需要考虑宕机风险和维护,任何为sso的提权行为都应该禁止.完全做到这两个才认为是比较好的sso方案
陈亦

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.

这难道不是本文所说的P3P的退出方式?那么你觉得aw和bw要不要提供接口呢?至于SSO要不要和应用分离,这是业务决定的。方案本文都已经说过了,P3P方式逐个清除登录态或逐个跳转方式清除登录态。SSO关联的应用一多,弊端立显。这又岂能称之为完美解决方案?像你所说的限制应用场景而称之的方案就更不能算了。

不针对应用是针对域名 只有不同域名下的才会逐个清除,而且是写一个功能的页面.我是不考虑多少应用,只考虑多少域名.我的也没有限制使用场景

应用和域名那只是实现的细节。你可以认为本文所说的每个应用都是一个独立的域名。

还是这两个:不建议sso和应用分离,不建议后台提权.sso和应用分离就需要考虑宕机风险和维护,任何为sso的提权行为都应该禁止.完全做到这两个才认为是比较好的sso方案

这个还不算有所限制么?刚才都说了SSO是否和应用分离是由业务决定的。在这里只是站在应用角度来讨论有无完美方案,关于宕机风险之类的根本就不是什么理由,有点牵强附会了。每个应用可能都有自身的一套体系架构,也或许是历史遗留问题,你倒不如直接说共享后端会话存储好了。如果这就是你所谓的完美方案,那我只能呵呵呵了。
光石头

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.

这难道不是本文所说的P3P的退出方式?那么你觉得aw和bw要不要提供接口呢?至于SSO要不要和应用分离,这是业务决定的。方案本文都已经说过了,P3P方式逐个清除登录态或逐个跳转方式清除登录态。SSO关联的应用一多,弊端立显。这又岂能称之为完美解决方案?像你所说的限制应用场景而称之的方案就更不能算了。

不针对应用是针对域名 只有不同域名下的才会逐个清除,而且是写一个功能的页面.我是不考虑多少应用,只考虑多少域名.我的也没有限制使用场景

应用和域名那只是实现的细节。你可以认为本文所说的每个应用都是一个独立的域名。

还是这两个:不建议sso和应用分离,不建议后台提权.sso和应用分离就需要考虑宕机风险和维护,任何为sso的提权行为都应该禁止.完全做到这两个才认为是比较好的sso方案

这个还不算有所限制么?刚才都说了SSO是否和应用分离是由业务决定的。在这里只是站在应用角度来讨论有无完美方案,关于宕机风险之类的根本就不是什么理由,有点牵强附会了。每个应用可能都有自身的一套体系架构,也或许是历史遗留问题,你倒不如直接说共享后端会话存储好了。如果这就是你所谓的完美方案,那我只能呵呵呵了。

主业务(负责登录)是有服务接口让第三方进行认证的,获取当前浏览器登录的用户,和后端session是否共享没有关系.
陈亦

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.

这难道不是本文所说的P3P的退出方式?那么你觉得aw和bw要不要提供接口呢?至于SSO要不要和应用分离,这是业务决定的。方案本文都已经说过了,P3P方式逐个清除登录态或逐个跳转方式清除登录态。SSO关联的应用一多,弊端立显。这又岂能称之为完美解决方案?像你所说的限制应用场景而称之的方案就更不能算了。

不针对应用是针对域名 只有不同域名下的才会逐个清除,而且是写一个功能的页面.我是不考虑多少应用,只考虑多少域名.我的也没有限制使用场景

应用和域名那只是实现的细节。你可以认为本文所说的每个应用都是一个独立的域名。

还是这两个:不建议sso和应用分离,不建议后台提权.sso和应用分离就需要考虑宕机风险和维护,任何为sso的提权行为都应该禁止.完全做到这两个才认为是比较好的sso方案

这个还不算有所限制么?刚才都说了SSO是否和应用分离是由业务决定的。在这里只是站在应用角度来讨论有无完美方案,关于宕机风险之类的根本就不是什么理由,有点牵强附会了。每个应用可能都有自身的一套体系架构,也或许是历史遗留问题,你倒不如直接说共享后端会话存储好了。如果这就是你所谓的完美方案,那我只能呵呵呵了。

主业务(负责登录)是有服务接口让第三方进行认证的,获取当前浏览器登录的用户,和后端session是否共享没有关系.

我觉得这次讨论你并没有坚持住你的立场。我是从你的论点出发来提出质疑的。或许你对完美方案的诠释跟我不一致。我至少认为完美的解决方案是应该解决我所提出的问题,否则那只能算是解决方案(好坏那是另外一回事)。至于cookie、session之类的基础知识没必要拿出来说。
光石头

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.

这难道不是本文所说的P3P的退出方式?那么你觉得aw和bw要不要提供接口呢?至于SSO要不要和应用分离,这是业务决定的。方案本文都已经说过了,P3P方式逐个清除登录态或逐个跳转方式清除登录态。SSO关联的应用一多,弊端立显。这又岂能称之为完美解决方案?像你所说的限制应用场景而称之的方案就更不能算了。

不针对应用是针对域名 只有不同域名下的才会逐个清除,而且是写一个功能的页面.我是不考虑多少应用,只考虑多少域名.我的也没有限制使用场景

应用和域名那只是实现的细节。你可以认为本文所说的每个应用都是一个独立的域名。

还是这两个:不建议sso和应用分离,不建议后台提权.sso和应用分离就需要考虑宕机风险和维护,任何为sso的提权行为都应该禁止.完全做到这两个才认为是比较好的sso方案

这个还不算有所限制么?刚才都说了SSO是否和应用分离是由业务决定的。在这里只是站在应用角度来讨论有无完美方案,关于宕机风险之类的根本就不是什么理由,有点牵强附会了。每个应用可能都有自身的一套体系架构,也或许是历史遗留问题,你倒不如直接说共享后端会话存储好了。如果这就是你所谓的完美方案,那我只能呵呵呵了。

主业务(负责登录)是有服务接口让第三方进行认证的,获取当前浏览器登录的用户,和后端session是否共享没有关系.

我觉得这次讨论你并没有坚持住你的立场。我是从你的论点出发来提出质疑的。或许你对完美方案的诠释跟我不一致。我至少认为完美的解决方案是应该解决我所提出的问题,否则那只能算是解决方案(好坏那是另外一回事)。至于cookie、session之类的基础知识没必要拿出来说。

我的立场就是那两点,跨域名退出是写了一个页面。我们的结果类似,实现方式不同,我主要是兼顾降低网络拓扑复杂度和稳定性和维护难度。我们也都用在了生产环境,各种各样都场景也都正常运行。
陈亦

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

引用来自“陈一回”的评论

引用来自“屁屁果”的评论

统一退出 是可以完美解决的.http://my.oschina.net/baobao/blog/199796

您应该是限制了使用场景吧?事实上各个应用如本文提到的aw, bw可能是不同子公司的产品,跟SSO不能共享后端会话存储。本文已经介绍过2个解决方案,一是P3P的方式,但这需要aw和bw提供接口;二是跳转方式。但这两种方式都有弊端。0

直接在浏览器通过js把 jsessionId删除,虽然后台没有session失效,前台是无法访问了,后台超时会自动失效,我目前就是这样做的,第三方系统不一定会给你提供操作会话的接口

这不是一样要接口么?否则aw的退出如何令bw的js来清除session id?

js 删除cookie,jsessionId也是cookie,没有jsessionid后台是无法识别当前用户的,会认为是非登录用户

这不是讨论js的cookie的问题吧?aw如何能让bw去清除它的js cookie?

iframe 等等方式都行.不建议sso和应用分离,不建议后台提权.只要满足这两个就行.

这难道不是本文所说的P3P的退出方式?那么你觉得aw和bw要不要提供接口呢?至于SSO要不要和应用分离,这是业务决定的。方案本文都已经说过了,P3P方式逐个清除登录态或逐个跳转方式清除登录态。SSO关联的应用一多,弊端立显。这又岂能称之为完美解决方案?像你所说的限制应用场景而称之的方案就更不能算了。

不针对应用是针对域名 只有不同域名下的才会逐个清除,而且是写一个功能的页面.我是不考虑多少应用,只考虑多少域名.我的也没有限制使用场景

应用和域名那只是实现的细节。你可以认为本文所说的每个应用都是一个独立的域名。

还是这两个:不建议sso和应用分离,不建议后台提权.sso和应用分离就需要考虑宕机风险和维护,任何为sso的提权行为都应该禁止.完全做到这两个才认为是比较好的sso方案

这个还不算有所限制么?刚才都说了SSO是否和应用分离是由业务决定的。在这里只是站在应用角度来讨论有无完美方案,关于宕机风险之类的根本就不是什么理由,有点牵强附会了。每个应用可能都有自身的一套体系架构,也或许是历史遗留问题,你倒不如直接说共享后端会话存储好了。如果这就是你所谓的完美方案,那我只能呵呵呵了。

主业务(负责登录)是有服务接口让第三方进行认证的,获取当前浏览器登录的用户,和后端session是否共享没有关系.

我觉得这次讨论你并没有坚持住你的立场。我是从你的论点出发来提出质疑的。或许你对完美方案的诠释跟我不一致。我至少认为完美的解决方案是应该解决我所提出的问题,否则那只能算是解决方案(好坏那是另外一回事)。至于cookie、session之类的基础知识没必要拿出来说。

我的立场就是那两点,跨域名退出是写了一个页面。我们的结果类似,实现方式不同,我主要是兼顾降低网络拓扑复杂度和稳定性和维护难度。我们也都用在了生产环境,各种各样都场景也都正常运行。

那我也没有说不能实现啊?2种方案我都给了。13所以抠字眼就没有必要了。
Leoops
目前ucenter的解决方案算是比较完美的了
陈亦

引用来自“李志威”的评论

目前ucenter的解决方案算是比较完美的了

SSO不可能完美实现,ucenter怎么着也是得基于这些原理,它不可能跳出去。只能说根据业务需求进行取舍。
稻草鸟人
可惜不是Java版的
陈亦

引用来自“稻草鸟人”的评论

可惜不是Java版的

因为Flask框架容易搭建测试环境以及完成测试原型,所以就选它了。理解了原理用什么语言实现都不是难事,别太纠结工具了。
×
陈亦
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: