Linux-命令-文件远程传输

发表于 2014-12-17 分类于系统

scp是有Security的文件copy，基于ssh登录。

命令基本格式：
scp [OPTIONS] file_source file_target

OPTIONS：

1
2
3

-v 和大多数 linux 命令中的 -v 意思一样 , 用来显示进度 . 可以用来查看连接、认证、 或是配置错误
-C 使能压缩选项
-P 选择端口 . 注意 -p 已经被 rcp 使用

拷贝单个文件至远程主机

1	scp ./test.txt root@192.168.1.100:/root/

远程文件/文件夹下载

1	scp -r root@192.168.62.10:/root/ ~/tmp/

tar命令详解

-c: 建立压缩档案
-x：解压
-t：查看内容
-r：向压缩归档文件末尾追加文件
-u：更新原压缩包中的文件

这五个是独立的命令，压缩解压都要用到其中一个，可以和别的命令连用但只能用其中一个。

下面的参数是根据需要在压缩或解压档案时可选的。

-z：有gzip属性的
-j：有bz2属性的
-Z：有compress属性的
-v：显示所有过程
-O：将文件解开到标准输出
-C：change to directory DIR
- 解包
  
  指定路径：tar -xvf FileName.tar -C ./target
- 打包
  
  tar -cvf file2.tar /home/usr2/file2。该命令可以将/home/usr2/file2文件打包到当前目录下的file2.tar中，需要注意的是：会将路径也打入包内。
  
  tar -cvf file2.tar -C /home/usr2 file2。该命令中的-C dir参数，将tar的工作目录从当前目录改为/home/usr2，将file2文件（不带绝对路径）压缩到file2.tar中。
  
  注意：-C dir参数的作用在于改变工作目录，其有效期为该命令中下一次-C dir参数之前。

参数-f是必须的

-f: 使用档案名字，切记，这个参数是最后一个参数，后面只能接档案名。

.tar

解包：tar -xvf FileName.tar
打包：tar -cvf FileName.tar DirName
（注：tar是打包，不是压缩！）

.gz

解压：gzip -d FileName.gz
压缩：gzip FileName

.tar.gz 和 .tgz

解压：tar -zxvf FileName.tar.gz
压缩：tar -zcvf FileName.tar.gz DirName

.tar.bz2

解压：tar -jxvf FileName.tar.bz2
压缩：tar -jcvf FileName.tar.bz2 DirName

.zip

解压：unzip FileName.zip
压缩：zip FileName.zip DirName

.rar

解压：rar -x FileName.rar
压缩：rar -a FileName.rar DirName

CAS 简介

What is CAS ？

CAS（ Central Authentication Service ）是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。

CAS 开始于 2001 年，并在 2004 年 12 月正式成为 JA-SIG 的一个项目。

主要特性

开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID、 RESTful API 、 SAML1.1 、 SAML2.0 等。
支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；
安全策略：使用票据（ Ticket ）来实现支持的认证协议；
支持授权：可以决定哪些服务可以请求和验证服务票据（ Service Ticket ）；
提供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；
支持多种客户端：Java 、.Net、PHP、Perl、Apache、uPortal 等。

SSO 单点登录原理

本文内容主要针对 Web SSO 。

什么是SSO

单点登录（Single Sign-On，简称 SSO）是目前比较流行的服务于企业业务整合的解决方案之一，SSO 使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

SSO 原理

SSO 体系中的角色

一般 SSO 体系主要角色有三种：

User（多个）
Web 应用（多个）
SSO 认证中心（1 个）

SSO 实现模式的原则

SSO 实现模式一般包括以下三个原则：

所有的认证登录都在 SSO 认证中心进行；
SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是已通过认证的用户；
SSO 认证中心和所有的 Web 应用建立一种信任关系，也就是说 web 应用必须信任认证中心。（单点信任）

SSO 主要实现方式

SSO 的主要实现方式有：

共享 cookies

基于共享同域的 cookie 是 Web 刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递 cookies 机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然 cookies本身不跨域，但可以利用它实现跨域的 SSO 。如：代理、暴露 SSO 令牌值等。

缺点：不灵活而且有不少安全隐患，已经被抛弃。

Broker-based（基于经纪人）

这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的 “第三方 “ 。例如 Kerberos、Sesame、IBM KryptoKnight（凭证库思想）等。Kerberos 是由麻省理工大学发明的安全认证服务，已经被 UNIX 和 Windows 作为默认的安全认证服务集成进操作系统。

Agent-based（基于代理人）

在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个 “ 翻译 “ 。例如 SSH 等。

Token-based

例如 SecureID,WebID ，现在被广泛使用的口令认证，比如 FTP 、邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。

基于网关
基于 SAML

SAML（Security Assertion Markup Language ，安全断言标记语言）的出现大大简化了 SSO，并被 OASIS 批准为 SSO 的执行标准。开源组织 OpenSAML 实现了 SAML 规范。

CAS 的基本原理

结构体系

从结构体系看，CAS 包括两部分：CAS Server 和 CAS Client。

CAS Server

CAS Server 负责完成对用户的认证工作，需要独立部署，CAS Server 会处理用户名 / 密码等凭证（Credentials）。

CAS Client

负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。

CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。

CAS 原理和协议

基础模式

基础模式 SSO 访问流程主要有以下步骤：

访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。
定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。
用户认证：用户身份认证。
发放票据： SSO 服务器会产生一个随机的 Service Ticket 。
验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。

下面是 CAS 最基本的协议过程：

如上图： CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时，CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket（ST 上图中的 Ticket），如果没有，则说明该用户是没有经过认证的；于是 CAS Client 会重定向用户请求到 CAS Server （ Step 2 ），并传递 Service （要访问的目的资源地址）。Step 3 是用户认证过程，如果用户提供了正确的 Credentials，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ），并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ）；CAS Client 在拿到 Service 和新产生的 Ticket 过后，在 Step 5 和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。

在该协议中，所有与 CAS Server 的交互均采用 SSL 协议，以确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程。但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的（使用 HttpsURLConnection ）。

CAS 请求认证时序图如下

CAS 如何实现 SSO

当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候，CAS Server 会主动获到这个 TGC cookie，然后做下面的事情：

如果 User 持有 TGC 且其还没失效，那么就走基础协议图的 Step4，达到了 SSO 的效果；
如果 TGC 失效，那么用户还是要重新认证（走基础协议图的 Step3）。

CAS 代理模式

该模式形式为用户访问 App1，App1 又依赖于 App2 来获取一些信息，如：User –>App1 –>App2。

这种情况下，假设 App2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致 User 的 IE 窗口不停地闪动），CAS 引入了一种 Proxy 认证机制，即 CAS Client 可以代理用户去访问其它 Web 应用。

代理的前提是需要 CAS Client 拥有用户的身份信息（类似凭据）。之前我们提到的 TGC 是用户持有对自己身份信息的一种凭据，这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借 TGC，User 可以免去输入密码以获取访问其它服务的 Service Ticket，所以，这里凭借 PGT，Web 应用可以代理用户去实现后端的认证，而无需前端用户的参与。

下面为代理应用（helloService）获取 PGT 的过程：（注：PGTURL 用于表示一个 Proxy 服务，是一个回调链接；PGT 相当于代理证；PGTIOU 为取代理证的钥匙，用来与 PGT 做关联关系；）

如上面的 CAS Proxy 图所示，CAS Client 在基础协议之上，在验证 ST 时提供了一个额外的PGT URL（而且是 SSL 的入口）给 CAS Server，使得 CAS Server 可以通过 PGT URL 提供一个 PGT 给 CAS Client。

CAS Client 拿到了 PGT（PGTIOU-85 … ..ti2td），就可以通过 PGT 向后端 Web 应用进行认证。

下面是代理认证和提供服务的过程：

如上图所示， Proxy 认证与普通的认证其实差别不大，Step1、2 与基础模式的 Step1、2 几乎一样，唯一不同的是，Proxy 模式用的是 PGT 而不是 TGC，是 Proxy Ticket（ PT ）而不是 Service Ticket。

辅助说明

CAS 的 SSO 实现方式可简化理解为：1 个 Cookie 和 N 个 Session。CAS Server 创建 cookie，在所有应用认证时使用，各应用通过创建各自的 Session 来标识用户是否已登录。

用户在一个应用验证通过后，以后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在 session 里读取到用户信息，所以就不会去 CAS Server 认证。如果在此浏览器里访问别的 web 应用时，客户端应用中的过滤器在 session 里读取不到用户信息，就会去 CAS Server 的 login 接口认证，但这时 CAS Server 会读取到浏览器传来的 cookie （ TGC ），所以 CAS Server 不会要求用户去登录页面登录，只是会根据 service 参数生成一个 Ticket ，然后再和 web 应用做一个验证 ticket 的交互而已。

术语解释

CAS 系统中设计了 5 中票据：TGC、ST、PGT、PGTIOU、PT。

Ticket-granting cookie（TGC）：存放用户身份认证凭证的 cookie，在浏览器和 CAS Server 间通讯时使用，并且只能基于安全通道传输（Https），是 CAS Server 用来明确用户身份的凭证；
Service ticket（ST）：服务票据，服务的惟一标识码，由 CAS Server 发出（Http 传送），通过客户端浏览器到达业务服务器端；一个特定的服务只能有一个惟一的 ST；
Proxy-Granting ticket（PGT）：由 CAS Server 颁发给拥有 ST 凭证的服务，PGT 绑定一个用户的特定服务，使其拥有向 CAS Server 申请，获得 PT 的能力；
Proxy-Granting Ticket I Owe You（PGTIOU）：作用是将通过凭证校验时的应答信息由 CAS Server 返回给 CAS Client，同时，与该 PGTIOU 对应的 PGT 将通过回调链接传给 Web 应用。Web 应用负责维护 PGTIOU 与 PGT 之间映射关系的内容表；
Proxy Ticket（PT）：是应用程序代理用户身份对目标程序进行访问的凭证；

其它说明如下：

Ticket Granting ticket（TGT）：票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，以后申请各种其他服务票据（ST）便不必再向 KDC 提交身份认证信息（Credentials）；
Authentication service（AS） ——— 认证用服务，索取 Credentials，发放 TGT；
Ticket-granting service（TGS） ——— 票据授权服务，索取 TGT ，发放 ST ；
KDC（Key Distribution Center） ———- 密钥发放中心；

CAS 安全性

CAS 的安全性仅仅依赖于 SSL。使用的是 secure cookie。

TGC/PGT 安全性

对于一个 CAS 用户来说，最重要是要保护它的 TGC，如果 TGC 不慎被 CAS Server 以外的实体获得，Hacker 能够找到该 TGC，然后冒充 CAS 用户访问所有授权资源。PGT 的角色跟 TGC 是一样的。

从基础模式可以看出，TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。

TGT 的存活周期默认为 120 分钟。

ST/PT 安全性

ST（Service Ticket）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket。CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）：

ST 只能使用一次

CAS 协议规定，无论 Service Ticket 验证是否成功，CAS Server 都会清除服务端缓存中的该 Ticket，从而可以确保一个 Service Ticket 不被使用两次。

ST 在一段时间内失效

CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。默认有效时间为 5 分钟。

ST 是基于随机数生成的

ST 必须足够随机，如果 ST 生成规则被猜出，Hacker 就等于绕过 CAS 认证，直接访问对应的服务。

Java-API-Java中的Copy-On-Write容器

发表于 2014-11-30 分类于 Java

转自：http://www.cnblogs.com/armyao/archive/2010/12/27/1917989.html

notifyAll使所有原来在该对象上等待被notify的线程统统退出wait的状态，变成等待该对象上的锁，一旦该对象被解锁，他们就会去竞争。
notify则文明得多他只是选择一个wait状态线程进行通知，并使它获得该对象上的锁，但不惊动其他同样在等待被该对象notify的线程们，当第一个线程运行完毕以后释放对象上的锁此时如果该对象没有再次使用notify语句，则即便该对象已经空闲，其他wait状态等待的线程由于没有得到该对象的通知，继续处在wait状态，直到这个对象发出一个notify或notifyAll，它们等待的是被notify或notifyAll，而不是锁。

Mybatis-用法-#{}和${}的区别

发表于 2014-11-27 分类于 Mybatis

#{}相当于jdbc中的preparedstatement，预编译
${}是输出变量的值，sql拼接

Web-Cookie和Session

发表于 2014-11-25 分类于 Web

转自：https://www.zhihu.com/question/19786827/answer/28752144

由于HTTP协议是无状态的协议，所以服务端需要记录用户的状态时，就需要用某种机制来识具体的用户，这个机制就是Session.典型的场景比如购物车，当你点击下单按钮时，由于HTTP协议无状态，所以并不知道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session，用用于标识这个用户，并且跟踪用户，这样才知道购物车里面有几本书。这个Session是保存在服务端的，有一个唯一标识。在服务端保存Session的方法很多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站，一般会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放在内存的，使用一些缓存服务比如Memcached之类的来放 Session。
思考一下服务端如何识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。有人问，如果客户端的浏览器禁用了 Cookie 怎么办？一般这种情况下，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。
Cookie其实还可以用在一些方便用户的场景下，设想你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以写到Cookie里面，访问网站的时候，网站页面的脚本可以读取这个信息，就自动帮你把用户名给填了，能够方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

Session

Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中。

Oracle-ORACLE中ROWNUM

发表于 2014-11-13 分类于 Oracle

ORACLE 中 ROWNUM

假设某个表 t1(c1) 有 20 条记录。

如果用 select rownum,c1 from t1 where rownum < 10，只要是用小于号，查出来的结果很容易地与一般理解在概念上能达成一致，应该不会有任何疑问的。

可如果用 select rownum,c1 from t1 where rownum > 10（如果写下这样的查询语句，这时候在您的头脑中应该是想得到表中后面 10 条记录），你就会发现，显示出来的结果要让您失望了，也许您还会怀疑是不谁删了一些记录，然后查看记录数，仍然是 20 条啊？那问题是出在哪呢？

先好好理解 rownum 的意义吧。因为 ROWNUM 是对结果集加的一个伪列，即先查到结果集之后再加上去的一个列（强调：先要有结果集）。简单的说 rownum 是对符合条件结果的序列号。它总是从 1 开始排起的。所以你选出的结果不可能没有 1，而有其他大于 1 的值。

rownum >10 没有记录，因为第一条不满足去掉的话，第二条的 ROWNUM 又成了 1，所以永远没有满足条件的记录。或者可以这样理解：

ROWNUM 是一个序列，是 oracle 数据库从数据文件或缓冲区中读取数据的顺序。它取得第一条记录则 rownum 值为 1，第二条为 2，依次类推。如果你用 >,>=,=,between…and 这些条件，因为从缓冲区或数据文件中得到的第一条记录的 rownum 为 1，则被删除，接着取下条，可是它的 rownum 还是 1，又被删除，依次类推，便没有了数据。

Linux-环境-profile、bashrc、bash_profile之间的区别和联系

发表于 2014-11-06 分类于系统

`/etc/profile`

此文件为系统的每个用户设置环境信息，当用户第一次登录时，该文件被执行。并从 /etc/profile.d 目录的配置文件中搜集 shell 的设置。

英文描述为：

1
2
3

# /etc/profile
# System wide environment and startup programs, for login setup # Functions and aliases go in /etc/bashrc
# It's NOT a good idea to change this file unless you know what you # are doing. It's much better to create a custom.sh shell script in # /etc/profile.d/ to make custom changes to your environment, as this # will prevent the need for merging in future updates.

所以如果你有对/etc/profile有修改的话必须得重启你的修改才会生效，此修改对每个用户都生效。

`/etc/bashrc`

为每一个运行 bash shell 的用户执行此文件。当 bash shell 被打开时，该文件被读取。

英文描述为：

1
2
3

# /etc/bashrc
# System wide functions and aliases # Environment stuff goes in /etc/profile
# It's NOT a good idea to change this file unless you know what you # are doing. It's much better to create a custom.sh shell script in # /etc/profile.d/ to make custom changes to your environment, as this # will prevent the need for merging in future updates.

如果你想对所有的使用 bash 的用户修改某个配置并在以后打开的 bash 都生效的话可以修改这个文件，修改这个文件不用重启，重新打开一个bash即可生效。

`~/.bash_profile`

每个用户都可使用该文件输入专用于自己使用的 shell 信息，当用户登录时，该文件仅仅执行一次！默认情况下，他设置一些环境变量，执行用户的 .bashrc 文件。

此文件类似于 /etc/profile，也是需要需要重启才会生效，/etc/profile 对所有用户生效，~/.bash_profile 只对当前用户生效。

`~/.bashrc`

该文件包含专用于你的 bash shell 的 bash 信息，当登录时以及每次打开新的 shell 时，该文件被读取.（每个用户都有一个 .bashrc 文件，在用户目录下）

此文件类似于 /etc/bashrc，不需要重启生效，重新打开一个 bash 即可生效，/etc/bashrc 对所有用户新打开的 bash 都生效，但 ~/.bashrc 只对当前用户新打开的 bash 生效。

`~/.bash_logout`

当每次退出系统（退出 bash shell）时，执行该文件.

另外，/etc/profile 中设定的变量（全局）的可以作用于任何用户，而 ~/.bashrc 等中设定的变量（局部）只能继承 /etc/profile 中的变量，他们是“父子”关系。

~/.bash_profile 是交互式 login 方式进入 bash 运行的；
~/.bashrc 是交互式 non-login 方式进入 bash 运行的；

通常二者设置大致相同，所以通常前者会调用后者。

Oracle-语法-复制表

发表于 2014-11-05 分类于 Oracle

直接建相同的表 create table students_backup as select * from students;
直接建相同的表结构 create table students_backup as select * from students where 1=2;
如果建好了表 insert into students_backup select * from students;

HTML4.01

XHTML1.0

HTML5