用户接口

D-Bus介绍

烂漫一生 提交于 2019-12-06 07:33:59
1 D-Bus 简介 D-Bus 是 Desktop Bus 的缩写,是针对桌面环境优化的 IPC(interprocess communication) 机制,用于进程间的通信或进程与内核的通信。 IPC 种类很多,适用的情景也不一样: CORBA 是用于面向对象编程中复杂的 IPC 的一个强大的解决方案。 DCOP 是一个较轻量级的 IPC 框架,功能较少,但是可以很好地集成到 K 桌面环境中。 SOAP 和 XML-RPC 设计用于 Web 服务,因而使用 HTTP 作为其传输协议。 D-BUS 设计用于桌面应用程序和 OS 通信。 D-Bus 中 D 是代表桌面“ Desktop ”的意思,即用于桌面操作系统的通信通道。现在逐渐被引入到嵌入式系统中,不过名字还是保留原先的叫法而已。 典型的桌面都会有多个应用程序在运行,而且,它们经常需要彼此进行通信。 DCOP 是一个用于 KDE 的解决方案,但是它依赖于 Qt ,所以不能用于其他桌面环境之中。类似的, Bonobo 是一个用于 GNOME 的解决方案,但是非常笨重,因为它是基于 CORBA 的。它还依赖于 GObject ,所以也不能用于 GNOME 之外。 D-BUS 的目标是将 DCOP 和 Bonobo 替换为简单的 IPC ,并集成这两种桌面环境。由于尽可能地减少了 D-BUS 所需的依赖,所以其他可能会使用 D

三大认证

▼魔方 西西 提交于 2019-12-06 06:14:39
三大认证 上次讲的 drf 还剩下 三大认证,当然也是从 APIView 的 dispatch 为入口。 def dispatch(self, request, *args, **kwargs): """ `.dispatch()` is pretty much the same as Django's regular dispatch, but with extra hooks for startup, finalize, and exception handling. """ self.args = args self.kwargs = kwargs request = self.initialize_request(request, *args, **kwargs) self.request = request self.headers = self.default_response_headers # deprecate? try: #这一步就做了三大认证,进去看源码。 self.initial(request, *args, **kwargs) # Get the appropriate handler method if request.method.lower() in self.http_method_names: handler = getattr(self,

Jenkins+Ant+Git+Jmeter接口自动化

一曲冷凌霜 提交于 2019-12-06 02:48:18
一、服务器分别安装JKD、Jenkins、Ant、Git、Jmeter 1、JKD安装参考: https://www.cnblogs.com/xiaoxitest/p/6168045.html 2、Jenkins安装参考: https://www.cnblogs.com/xiaoxitest/p/11947309.html 3、Ant安装参考: https://www.cnblogs.com/xiaoxitest/p/11947205.html 4、Git安装参考: https://www.cnblogs.com/xiaoxitest/p/10106302.html 5、Jmeter安装参考: https://www.cnblogs.com/xiaoxitest/p/6208940.html 二、Ant配置 1、将jmeter的extras目录下ant-jmeter-1.1.1.jar文件拷贝到ant的lib目录下 2、创建存放测试报告目录:/opt/apache-jmeter-5.1.1/report/html 和 /opt/apache-jmeter-5.1.1/report/jtl 3、由于默认的报告内容不够丰富,下载style文件: jmeter.results.shanhe.me.xsl ,把下载的文件放到jmeter的extras目录下 4、修改jmeter

ATM_购物车

笑着哭i 提交于 2019-12-05 23:40:34
ATM+购物车 目录 ATM购物车 一、一个项目是如何从无到有的 二、项目需求 三、项目开发 random.txt 项目说明文件 start.py 项目启动文件 conf--------setting.py 系统环境变量配置 core------src.py 业务核心逻辑 db-----db_hander.py 真实数据层 interface-----admin_interface.py 管理员接口 interface----bank_interface.py 银行接口 interface----shoping_interface.py 购物接口 interface----user_interface.py 用户接口 lib----common.py 公共功能 ATM购物车 一、一个项目是如何从无到有的 1.需求分析 注册,登陆,查看余额,支付,购物车, 提现,还款,转账,查看流水,注销,管理员, 查看购物车,登陆认证装饰器, 密码加密 2.程序的架构设计 三层架构: 用户功能层: 接收用户输入的内容,展示给用户的内容. 小的逻辑判断,例如两次密码是否一致. 接口层: 处理业务逻辑. 数据处理层: 对数据进行增删查改. 3.分任务开发 4.测试 5.上线运行 二、项目需求 1.注册 2.登录 3.转账 4.查询余额 5.还款 6.取款 7.查看流水 8.购物 9.查看购买商品 10

菜单

时光毁灭记忆、已成空白 提交于 2019-12-05 22:40:04
紫光工业互联网平台应用服务开发 ( 统一用户认证对接 ) 修订历史记录 日期 版本 说明 作者 2019/05/16 V1.0 初版 紫光云引擎项目组 1 引言 1.1 文档目的 为紫光工业互联网平台编写统一用户认证对接方案,其目的为实现本平台纳管其他子平台用户,最终实现从本平台跳转登录其他子平台时实现用户免登陆并且用户信息同步的原则。 1.2 方案背景 n 本平台发起登录,登录成功,过后跳转其他子平台。 n 第三方平台发起登录,至本平台验证用户,验证成功,第三方平台登录成功。 2 统一用户认证对接 2.1 方案一 本平台发起登录,登录成功,过后跳转其他子平台。 目前子平台主要包括物联网平台、大数据平台、态势感知平台等。对接方案主要为用户登录使用本平台后,希望访问子平台,本平台根据用户信息生成一串加密后的Token ,携带 Token 跳转子平台,子平台接收 Token 后反向使用 Token 至本平台换取用户信息,子平台得到用户信息后,需要验证子平台是否有该用户信息,如没有则保存该用户信息同时赋予初始角色与权限,如有则使用该用户在子平台的角色和权限。 携带Token 登录使用 Token 换取用户信息 2.2 接口设计 公共参数说明: success :接口状态, true- 正常, false- 异常 message :接口返回值描述 data :返回数据,默认为空字符串 接口

Linux电源管理(7)_Wakeup events framework

£可爱£侵袭症+ 提交于 2019-12-05 20:35:57
1. 前言 本文继续“Linux电源管理(6)_Generic PM之Suspend功能”中有关suspend同步以及PM wakeup的话题。这个话题,是近几年Linux kernel最具争议的话题之一,在国外Linux开发论坛,经常可以看到围绕该话题的辩论。辩论的时间跨度和空间跨度可以持续很长,且无法达成一致。 wakeup events framework是这个话题的一个临时性的解决方案,包括wake lock、wakeup count、autosleep等机制。它们就是本文的话题。 2. wakeup events framework要解决的问题 我们知道,系统处于suspend状态,可通过wakeup events唤醒。具体的wakeup events可以是按键按下,可以是充电器插入,等等。但是,如果在suspend的过程中,产生了wakeup events,怎么办?答案很肯定,"wakeup"系统。由于此时系统没有真正suspend,所以这的"wakeup"是个假动作,实际上只是终止suspend。 但由于系统在suspend的过程中,会进行process freeze、 device suspend等操作,而这些操作可能导致内核或用户空间程序不能及时获取wakeup events,从而使系统不能正确wakeup,这就是wakeup events

测试过程

与世无争的帅哥 提交于 2019-12-05 20:02:04
软件生命周期 软件测试要经过一个什么样的过程呢,这就要从软件的生命周期开始说起了。 软件生命周期又称为软件生存周期或系统开发生命周期,是软件的产生直到报废的生命周期。 整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。 在周期内,无论是开发还是测试都依赖于某个模型进行作为依据,有效地提高开发、测试效率。 软件开发模型 在软件开发的实践中,总结了很多软件的开发模型来描述和表示一个复杂的开发过程,如果瀑布模型、快速原型模型、螺旋模型等。 软件测试与软件开发模式有着紧密的关系,作为一名测试人员,应该充分理解软件的开发模式,尽快的找准自己的位置,从而尽快的发挥自己的价值。 瀑布模型 瀑布模型是线性模型的一种,在所有的模型中占有重要的地位,是所有其他模型的一个基础。 瀑布模型如同工地里的建造盖房流程,使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。 测试的切入点,开发完成后,必须留给测试足够的时间给测试人员,否则可能会导致测试不充分,导致很多问题到项目的后期才体现出来。 优点 明确划分了软件生命周期的各个环节。 强调早期软件计划,需求分析比较重要。 清晰的工作流程,便于分工协作。 适合需求稳定的产品开发。 每个阶段都有一个检查点。 缺点 线性的开发流程,存在巨大的风险。 依赖于早期的需求调查

LTE基本架构

余生长醉 提交于 2019-12-05 19:55:10
1、LTE结构 这是一张非常有名的LTE架构图,从图中可以看出,整个网络构架被分为了四个部分:   (1)UE就可以看作是我们的手机终端    (2)PDN可以看作是网络上的服务器 (3)E-UTRAN可以看作是遍布城市的各个基站(可以是大的铁塔基站,也可以是室内悬挂的只有路由器大小的小基站)   (4)EPC可以看作是运营商(中国移动/中国联通/中国电信)的核心网服务器,核心网包括很多服务器,有处理信令的,有处理数据的,还有处理计费策略的等等。 2、专用词汇 UE 全称是User Equipment,用户设备,就是指用户的手机,或者是其他可以利用LTE上网的设备。 eNB 是eNodeB的简写,它为用户提供空中接口(air interface),用户设备可以通过无线连接到eNB,也就是我们常说的基站,然后基站再通过有线连接到运营商的核心网。在这里注意,我们所说的无线通信,仅仅只是手机和基站这一段是无线的,其他部分例如基站与核心网的连接,基站与基站之间互相的连接,核心网中各设备的连接全部都是有线连接的。一台基站(eNB)要接受很多台UE的接入,所以eNB要负责管理UE,包括资源分配,调度,管理接入策略等等。 MME 是Mobility Management Entity的缩写,是核心网中最重要的实体之一,提供以下的功能: NAS 信令传输,NAS信令指的是三层信令,包含EMM,

Spring Boot 2.X(十八):集成 Spring Security-登录认证和权限控制

半城伤御伤魂 提交于 2019-12-05 17:01:52
前言 在企业项目开发中,对系统的安全和权限控制往往是必需的,常见的安全框架有 Spring Security、Apache Shiro 等。本文主要简单介绍一下 Spring Security,再通过 Spring Boot 集成开一个简单的示例。 Spring Security 什么是 Spring Security? Spring Security 是一种基于 Spring AOP 和 Servlet 过滤器 Filter 的安全框架,它提供了全面的安全解决方案,提供在 Web 请求和方法调用级别的用户鉴权和权限控制。 Web 应用的安全性通常包括两方面:用户认证(Authentication)和用户授权(Authorization)。 用户认证指的是验证某个用户是否为系统合法用户,也就是说用户能否访问该系统。用户认证一般要求用户提供用户名和密码,系统通过校验用户名和密码来完成认证。 用户授权指的是验证某个用户是否有权限执行某个操作。 2.原理 Spring Security 功能的实现主要是靠一系列的过滤器链相互配合来完成的。以下是项目启动时打印的默认安全过滤器链(集成5.2.0): [ org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter

drf三大认证

允我心安 提交于 2019-12-05 16:28:25
三大认证任务分析 认证模块:校验用户是是否登陆 self.perform_authentication(request) 权限模块:校验用户是否拥有权限 self.check_permissionsn(request) 频率模块:访问接口的次数在设定的时间范围内是否过快(配置访问频率、缓存计次、超次后需要等待的时间) self.check_throttles(request) auth组件的认证权限六表 也就是基于角色的访问控制:基于角色的访问控制(RBAC)是实施面向企业安全策略的一种有效的访问控制方式。 Django框架采用的是RBAC认证规则,RBAC认证规则通常会分为 三表规则、五表规则,Django采用的是六表规则 三表:用户表、角色表、权限表 五表:用户表、角色表、权限表、用户角色关系表、角色权限关系表 六表:用户表、角色表、权限表、用户角色关系表、角色权限关系表、用户权限关系表 举个栗子:看图说话 所以我们需要建立关联表(python中是六张表) 我们在实际开发中可能要重写六表 在python中的数据库中会有这六张表eg:用户表中会有用户名、密码、是否是超级管理员、是否是活跃用户等 在auth_permission中的Content_type:给Django中的所有模块中的所有表进行编号存储到Content_type中 应用一:权限表的权限是操作表的