分类：未分类

理解OAuth 2.0

OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。

本文对OAuth 2.0的设计思路和运行流程，做一个简明通俗的解释，主要参考材料为RFC 6749。

OAuth Logo

一、应用场景

为了理解OAuth的适用场合，让我举一个假设的例子。

有一个”云冲印”的网站，可以将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让”云冲印”读取自己储存在Google上的照片。

云冲印

问题是只有得到用户的授权，Google才会同意”云冲印”读取这些照片。那么，”云冲印”怎样获得用户的授权呢？

传统方法是，用户将自己的Google用户名和密码，告诉”云冲印”，后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。

（1）”云冲印”为了后续的服务，会保存用户的密码，这样很不安全。

（2）Google不得不部署密码登录，而我们知道，单纯的密码登录并不安全。

（3）”云冲印”拥有了获取用户储存在Google所有资料的权力，用户没法限制”云冲印”获得授权的范围和有效期。

（4）用户只有修改密码，才能收回赋予”云冲印”的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。

（5）只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

OAuth就是为了解决上面这些问题而诞生的。

继续阅读理解OAuth 2.0

CSS字体大小: em与px、pt、百分比之间的对比

CSS样式最混乱的一个方面是应用程序中文本扩展的font-size属性。在CSS中,你可以用四个不同的单位度量来显示在web浏览器中的文本大小。这四个单位哪一种最适合Web? 这个问题引起了广泛的争论。找到一个确定的答案是困难的, 因为这个问题,本身就是如此难以回答。

　　接触这些单位

1.  “Ems”(em):“em”是一个可伸缩的单位, 用于web文档媒体展示。一个em等于当前的字体大小,例如,如果文档的字体大小是12 pt,1 em等于12 pt。Ems在本质上是可伸缩的,所以2 em相当于24 pt，.5 em相当于6 pt等。ems由于其可伸缩性和适应移动设备的特性在web文档中正变得越来越受欢迎。

2.  像素(px):像素是固定大小的单元,用于屏幕媒体(即在电脑屏幕上读取)。一个像素等于电脑屏幕上的一个点 (是你屏幕分辨率的最小分割)。许多网页设计师在web文档使用像素单位以生产浏览器渲染的像素完美呈现的网站。像素单元的一个问题是,它没有为视障读者的扩展,以适应移动设备。

3.  点(pt):点通常用于印刷媒体(任何打印在纸上的媒体,等等)。一个点等于一英寸的1/72。点更像像素,他们是固定大小的单位,不能伸缩。

4. 百分比(%):百分比单位更像“em”单位,除了一些根本性的差异。首先,当前的字体大小等于100%(比如12 pt = 100%)。当使用百分比单位,你的文字在移动设备上仍然保持完全的可伸缩性和可访问性。 继续阅读CSS字体大小: em与px、pt、百分比之间的对比

Android常用知识点总汇

一、系统上安装了多种浏览器，能否指定某浏览器访问指定页面？请说明原由。

如果在你的android系统上安装了多种浏览器，能否指定某浏览器访问指定页面？答案当然是：肯定的。

具体方法如下：

Intent intent = newIntent();

intent.setAction(“android.intent.action.VIEW”);

Uri content_uri_browsers = Uri.parse(“http://isomobile.com”);

intent.setData(content_uri_browsers);

intent.setClassName(“com.android.browser”, “com.android.browser.BrowserActivity”);

startActivity(intent);

问题的关键在于我们设置了class name，也就是我们想要跳转的pakcage的activity。如果你想要跳转到其它的浏览器，只需要修改一下这个函数就OK了。

好，我们现在来让刚刚的思路来指导我们的实践。假如我们现在要直接启动UC浏览器，那么我们该怎么做呢？让我们step by step吧。

1）下载UC apk：

http://i-uc.net/read.php?2

2）用7zip解压apk文件，得到classes.dex文件

3）下载反编译dex文件工具：

http://nchc.dl.sourceforge.net/project/dedexer/dedexer/1.5/ddx1.5.jar（Dedexer 项目主页:http://dedexer.sourceforge.net/

） 继续阅读Android常用知识点总汇

常用Linux命令

1、查看sshd是否已经是系统服务

# chkconfig –list |grep sshd
会显示：
 sshd    0:off 1:off 2:off 3:off 4:off 5:off 6:off
使用如下命令设置sshd服务自动启动：
# chkconfig –level 5 sshd on
2、检查服务是否启用

ps -ef | grep ssh
3、安装服务
yum install openssh-server
4、安装完之后开启 

/etc/init.d/sshd start
5、

以安装成服务的tomcat环境设置远程调试功能

此种情况就是针对将tomcat安装成本地服务了，但是又想进行远程调试的情况，别说改catalina.bat，就是应为改不了才尝试其他办法的。

你可以通过如下方式来编辑Tomcat的服务启动参数来调试安装成Tomcat服务后的web应用程序。

 

打开命令提示符

设置CATALINA_HOME环境变量，把其指向tomcat主目录 例如：set CATALINA_HOME=d:tomcat6

运行如下命令：%CATALINA_HOME%bintomcat6w.exe //ES//<这里填写你的Tomcat的服务名> 当然了，我的服务名是自定制过的，不是tomcat6

弹出了一个服务编辑框神马的，然后再在“属性”框上选择 Java 标签，打开后有很多配置的选项，神马都是浮云，不用理会

直接找到Java Options文本输入区域，然后在里头添加如下两行：

-Xdebug

-Xrunjdwp:transport=dt_socket,address=9999,server=y,suspend=n

如果你只想在本机进行tomcat的调试，那么将address=9999的9999替换成127.0.0.1:9999，这样你就只能在本机调试了，上述的方法是保证你在任何能访问到的机器上都能调试你的tomcat的配置哦，小心点为妙。

点击”Apply”，然后点击”OK”关闭对话框

重启你的Tomcat服务器，然后检查一下，是不是发现9999端口监听了呢？通过netstat -an命令何以查看哦。

使用IDE通过9999端口连接到Tomcat，开始你的远程调试之旅吧

如果你已经使用了Eclipse,你可以在Remote Debugging with Eclipse获得更多信息。

WebSocket 协议

译者： coderbee (wen866595@163.com)
转载请注明出处

翻译自： http://tools.ietf.org/rfc/rfc6455.txt

Internet Engineering Task Force (IETF)                                                       I. Fette
Request for Comments: 6455                                                                      Google, Inc.
Category: Standards Track                                                                          A. Melnikov
ISSN: 2070-1721 Isode Ltd.                                                                         December 2011

WebSocket 协议

摘要

WebSocket协议使在控制环境下运行不受信任代码的客户端和能够选择与那些代码通信的远程主机之间能够双向通信。用于这个的安全模型是以origin为基础的安全模型，一般被浏览器使用。协议包含打开握手，其次是基本消息框架，在 TCP 之上。这项技术的目的是为基于浏览器的、需要与服务器双向通信的应用程序提供一种不依赖于打开多个HTTP连接的机制（例如，使用XMLHttpRequest 或 <iframe> 和长轮询）。

本备忘录的状态

这是一个Internet标准跟踪文件。

这个文档是因特网工程师任务组（IETF）的一个产品。它代表了IETF社区的共识。它已接受公众审查，因特网工程指导组（IESG）证明可出版。关于互联网标准的进一步信息在RFC5741的第2章节。

关于本文档当前状态的信息、勘误表和如何提供反馈，可以在 http://www.rfc-editor.org/info/rfc6455 找到。

版权声明

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1 介绍

1.1 背景

这部分是不规范的。

历史上，创建需要在客户端和服务器间双向通信的网络应用程序（如即时消息和游戏程序）要求滥用 HTTP 来轮询服务器来获得更新，通过不同 HTTP 请求来发送上行通知。

这导致各种问题：

  • 服务器被迫为每个客户端使用一些不同的底层TCP连接：一个用来向客户端发送消息，为每个到来的消息使用一个新的。
  • 通信（wire）协议具有很高的开销，因为每个客户端到服务器的消息有HTTP头。
  • 客户端侧的脚本被迫维护输出连接到输入连接的映射来追踪响应。

一个简单的解决方法是为双向传输使用单一的TCP连接。这是WebSocket协议提供的。结合WebSocket API（WSAPI），它为web页面到远程服务器的双向通信提供了HTTP轮询的替代方案。

同样的技术也可用于各种web应用程序：游戏，股票行情，多用户协同编辑的应用程序，用户界面实时展示服务器侧服务等。

WebSocket协议设计用来取代使用HTTP作为传输层的双向通信技术，并从现有的基础设施（代理、过滤、认证）受益。这些技术作为效率与可靠性的平衡而实现，因为HTTP最初并不是用于双向通信的（见RFC6202有多更讨论）。WebSocket尝试解决在现有HTTP基础设施的环境下现有HTTP双向通信技术的目标；像这样，它设计来工作于HTTP 80、443端口上，并支持HTTP代理和中间设施，即使这意味着增加现有环境的一些复杂性。然而，设计并没有将WebSocket局限于HTTP，未来的实现可以在特定的端口上使用更简单的握手，而不需要重新发明整个协议。最后一点是重要的，因为交互式消息的传输模式并不紧密符合标准的HTTP传输，会在一些部件上引起异常的负载。

继续阅读WebSocket 协议