laravel auth

two ways to authentication, based on session(cookie) or based on api(token),so we have two guards (web & api in config/auth.php).

guards have a driver and a provider,actually it’s just like controller and model.
driver: the logic u handle authentication
model: where u store your user data

#how it works
At first ,we need an entrance, we need to define some route.that’s why laravel map the route in provider/RouteServiceProvider

in RouteServiceProvider we have added a list of middlewares and  our custom route.
(Auth::routes() in web guard, https://stackoverflow.com/questions/39196968/laravel-5-3-new-authroutes)
(in api guard, we need to add auth:api in middleware if u need authentication. like this :   Route::middleware(‘auth:api’)->group(…))

when u use Auth->attempt(), Auth->user() in your program, it’s actually interact from SessionGuard or TokenGuard.
(Auth alias AuthManager initialize a guard in the construction,and transfer the request to the guard)

 

ceph command

#check ceph usage
ceph df detail

#create s3 user
radosgw-admin user create –uid={username} –display-name=”{display-name}” [–email={email}]

#list s3 user and get info
radosgw-admin metadata list user
radosgw-admin user info –uid=[username]

#resharding
http://docs.ceph.com/docs/mimic/radosgw/dynamicresharding/

#check bucket index
radosgw-admin bucket stats –bucket=[bucket name]

#ceph report(lots of info)
ceph report

pipeline in laravel

Reference: https://segmentfault.com/a/1190000010092899?utm_medium=hao.caibaojian.com&utm_source=hao.caibaojian.com&share_user=1030000000178452

The concept is easy to understand,but the code is so confused. Every pipe will be run in order . Also they will get the data given by the previous pipe.

let’s see how Laravel get the job done .

Before dispatching  the request to router , Laravel will go through all the middleware first. The request object will be passed through all the middleware. middleware array is in the App\Http\Kernel

reference: array_reduce
array_reduce(pipes,callablecallable,initial)this->carry() will return a closure . two parameters (stack,pipe)  will be provided into this closure function . stack is the return value of the previous pipe.item is the current pipe. And initial will be the firststack, it’s a closure function too.

=====>

The following is how the pipe iterations work.
——————————————————–
let’s say  pipe = [middleware1, middleware2] array_reverse will reverse thepipe array,so pipe = [middleware2,middleware1] ====================first iteration===================stack = dispatchToRouter
pipe = middleware2 so the return value = return function (passable) use (dispatchToRouter ,middleware2) { //….}
Let’s look into detail. u can see the passable andstack will pass into the middleware  as parameters.
it’s time to find out how a middleware looks like.

it will run the next function at the end of the handle function, and thenext is equal to stack.so it means it will call thestack at the end.
so the execute order looks like this :
dispatchToRouter  <- -call–  middleware2
=================second iteration=====================
stack = a closure return by first iterationpipe = middleware1
the same as first iteration, the return value will be a closure.
and the execute order will be :
dispatchToRouter <–call–middleware2 <–call– middleware1
========================done=======================
u may be confuse ,they are all closure. when will all these closure get called?
look carefully into the then() function.
the last iteration will return a closure. and the then() function  invoke the closure and pass the request object as a parameter.

that’s it!

 

how dependency injection and container develop

reference : http://jaceju.net/2014-07-27-php-di-container/

why we need dependency injection ?
cause we want to remove  dependency. Instead of creating object in the inner, we pass the object via parameter during construction.

if we want to change the way we auth or how session store, we may need to change class app too.

much better now,and we want different ways to auth,we had better to change auth to interface

looks great, then why we need the container?
sometimes we don’t know which way we want until we run the program.(http or db auth). we can register the class we want into a container,and retrieve later.

looks perfect,but every time we need to create an app object,we need to write all this code. it’s a wise choice to wrap them into a function.

could we make it better?
yes,we can. Every time we create an app object, we have to inject the dependency into container. what if the container can auto load the dependency by itself, then we can free from providing the dependency. it’s time to present reflection class.
http://php.net/manual/en/class.reflectionclass.php

holy shit,only one line code we got what we want.

 

html summary

1.html entity 轉換

显示结果 描述 实体名称 实体编号(10進制&16進制)
空格 &nbsp; &#160;(&#xA0;)
< 小于号 &lt; &#60;(&#x3C;)
> 大于号 &gt; &#62;(&#x3e;)
& 和号 &amp; &#38;(&#x26;)
双引号 &quot; &#34;(&#x22;)
单引号 &apos; &#39;(&#x27)

2.cache
#don’t use cache:
cache-control:no-store
cache-control:no-cache
(redo anything no matter what)
#use cache
cache-control:max-age:[second]
expires: [date]
cache-control:public
cache-control:private
validation:
(1) if set expires or max-age, and the cache is still fresh, browser will load the file direct from cache,without making a request.
(2) if browser can not load cache from local, it will send request to server to validate whether the cache is still fresh,if yes,return 304 , or  handle the request.
last-modified/if-modified-since
Etag/if-none-match
(3)if no caches are available, browser will send request to  server

3.same origin policy & cors
ref:
https://web-security.guru/en/web-security/same-origin-policy
http://www.ruanyifeng.com/blog/2016/04/cors.html
https://enable-cors.org/

sop:
same protocol
same domain
same port
we can load  img ,video,script etc from other domain,but we can’t
(1)Reading Ajax responses via XMLHttpRequest and fetch from another origin
(2)Reading and writing the Document Object Model (DOM) of another origin
(3)Reading and writing stored data (Cookie, session & local storage) of another origin

cors:
create a white list to allows one origin to access resources from another origin.
It can not secure your content , but it can protect innocent user from running scripts in a malicious website.  Because the malicious website does not in the  Access-Control-Allow-Origin.
if u want to share your content to other origin, also keep confidential,u can use Oauth2

security summary

u can’t trust user input

1.sql injection
attack:
u need urlencode
1.login bypass (‘ or 1=1 /*)
2.integer bypass( 1;drop table users)
3.select information(‘ union select username,NULL,NULL from user /*)
4.insert or update information (‘ update  groupid where user = 100 /*)
5.second order injection(create a user name like ‘ drop table user/*,single quote may be correctly encoded and store this record into db.when u execute query with this username,problem occur)
protection:
prepared statement

2.image upload
attack:
1.upload php file directly,no extension check
2.filename with invisible character(fool.php(%00).jpg) pass the extension check,but store in server as fool.php
protection:
if there is a upload file
validate upload path(is_empty,is_dir,is_writable)
if upload success
check extension (white list extension)
check mime(white list mime)
check filename(limit length,no invisible character,remove space)
check size and dimension
rename file
do not overwrite file

3.csrf
attack:
1.forces an end user to execute unwanted actions on a web application in which they’re currently authenticated by sending a link via email or chat(transfer money via e-banking)
protection:
add csrf token in cookie,check the token in the backend,then regenerate. make sure the request was sent by the correct end user.
two-factor authentication

4.xss
attack:
http://wooyun.jozxing.cc/search?keywords=author%3A+%E5%BF%83%E4%BC%A4%E7%9A%84%E7%98%A6%E5%AD%90&content_search_by=by_bugs
1.反射型xss

2.dom xss

protection:
1.http-only cookie(prevent read cookie from document)
2.use htmlspecialchars with ENT_QUOTES to filter output in html

 

php summary

1.cgi & fastCgi
request(index.php)->webserver–(cgi)–>php interpreter(need to initialize environment every time)
cgi is a protocal,standardize the data transmitted between the web server and the php interpreter.(post data,header data,url,query string)

request(index.php)->webserver–(fastCgi)—>php interpreter(don’t need to initialize environment every time, a master will handle this)
fastCgi is a protocal as well. But instead initialize environment every time when a request comes in, fastCgi will create a master handle the initialization,and fork a php interpreter worker to handle the request.php-fpm is a fastCgi program.

2.psr
https://github.com/php-fig/fig-standards/tree/master/accepted
https://github.com/squizlabs/PHP_CodeSniffer

3.

[轉載]非对称加密方法

非对称加密方法
1公钥私钥的使用原则
①每一个公钥都对应一个私钥。
②密钥对中,让大家都知道的是公钥,不告诉大家,只有自己知道的,是私钥。 ③如果用其中一个密钥加密数据,则只有对应的那个密钥才可以解密。
④如果用其中一个密钥可以进行解密数据,则该数据必然是对应的那个密钥进行的加密。非对称密钥密码的主要应用就是公钥加密和公钥认证。
2公钥加密、解密
加密的目的,是不希望第三者看到当前两个通讯用户的通讯内容。2.1加密
A(客户)想给B(服务器)发送一段文字,但是不想让别人看到,因此想使用非对称加密方法来加密这段文字,当然,B需要有一对公钥和私钥:
① B将他的公钥发送给A
② A用B给他的公钥加密这段文字,然后传给B
③ B用他的私钥解密A发过来的消息,这里要强调的是,只要B的私钥不泄露,这封信就是安全的,即使落在别人手里,也无法解密。
通过这几步,B就能成功收到A发送的信息,同时又达到了保密的目的。

2.2解密
如果B想给A回信息,就简单的多了:
① B将要回复的信息通过自己的私钥加密,然后传送给A

② A用B之前给他的公钥解出这份信息。
3、公钥认证
在2公钥加密、解密里面描述的通讯过程看似简单,但想想这个问题:在过程2中,A怎么B给他的回信在传递过程中,有没有被人修改?这就涉及到数字签名的概念。3.1数字签名(digital signature)
微软官方给出的定义:“数字签名”是指可以添加到文件的电子安全标记。使用它可以验证文件的发行者以及帮助验证文件自被数字签名后是否发生更改。3.1.1数字签名原理
要达到这个目的,一般是对信息做一个hash计算得到一个hash值,注意,这个过程是不可逆的,也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时,把这个hash值加密后做为一个签名和信息一起发出去。 接收方在收到信息后,会重新计算信息的hash值,并和信息所附带的hash值(解密后)进行对比,如果一致,就说明信息的内容没有被修改过,因为这里hash计算可以保证不同的内容一定会得到不同的hash值,所以只要内容一被修改,根据信息内容计算的hash值就会变化。当然,不怀好意的人也可以修改信息内容的同时也修改hash值,从而让它们可以相匹配,为了防止这种情况,hash值一般都会加密后(也就是签名)再和信息一起发送。

3.1.2数字签名使用方式
下面通过例子来说明这个过程:
B给A回信时,采用了数字签名的方式
1、B先用hash函数,生成信件的摘要(digest)
2、B使用自己的私钥,对这个摘要加密,这样就生成了数字签名(signature)
3、B将这个签名附在要回复的信息后面,一起发给A
4、A收到B的信息后,取下数字签名,并通过B的公钥解密,得到信件的摘要信息

5、A在对B发送的信息本身使用B指定的hash函数,将得到的结果同上一步解密得到的摘要进行对比,如果两者一致,就说明B发过来的信息未被修改过。
3.2数字证书(Digital Certificate)
问题就这样结束了吗?远没有,试想,虽然A确定了B回给他的信息是未修改过的,但是怎么确定给他回信息的就是B?如果有不怀好意的C把A保存的B的公钥偷偷换成自己的,并冒用B的名义给A发信息呢?
要解决这个问题,A只要能确定自己持有的公钥到底是不是B的就行了,这就需要用到数字证书。
数字证书是用来验证公钥所属的用户身份。在日常生活中,如果我们要验证一个人的身份,通常的做法是查看他的身份证。我们信任身份证颁发机构即政府机构的公信力,因此只要验证一个人的身份证不是伪造的,我们就相信这个人的身份和身份证上所描述的是一致的。
数字证书就是一个人或者组织在网络世界中的身份证,其发证机关是证书管理机构(certificate authority,CA)。CA用自己的私钥对用户的身份信息(主要是用户名和该用户的公钥)进行签名,该签名和用户的身份信息一起就形成了证书。
3.2.1数字证书的构成
 证书的发布机构(Issuer)
指出是什么机构发布的这个证书,也就是指明这个证书是哪个证书中心(certificate authority,简称CA)发布的的(只是创建证书,不是指证书的使用者)。
 证书的有效期(Valid from , Valid to)
也就是证书的有效时间,或者说证书的使用期限。 过了有效期限,证书就会作废,不能使用了。
 公钥 (Public key)
这个我们在前面介绍公钥密码体制时介绍过,公钥是用来对消息进行加密解密的,是很长的一串数字。
 证书所有者(Subject)
这个证书是发布给谁的,或者说证书的所有者,一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。
 签名所使用的算法 (Signature algorithm)
指的这个数字证书的数字签名所使用的加密算法,这样就可以使用证书发布机构的证书里面的公钥,根据这个算法对指纹进行解密。指纹的加密结果就是数字签名
 指纹以及指纹算法 (Thumbprint, Thumbprint algorithm)
这个是用来保证证书的完整性的,也就是说确保证书没有被修改过。 其原理就是在发布证书时,发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起,使用者在打开证书时,自己也根据指纹算法计算一下证书的hash值(指纹),如果和刚开始的值对得上,就说明证书没有被修改过,因为证书的内容被修改后,根据证书的内容计算的出的hash值(指纹)是会变化的。
3.2.2数字证书的生成过程
1、使用数字证书申请者的身份信息生成数字签名

2、将证书申请者的身份信息和数字签名一起组成数字证书

3.2.3数字证书原理
有了数字证书以后,A和想跟B通信,就可以通过B的数字证书来获取B的公钥,以达到验证自己手中的公钥到底是不是B的目的。过程是这样的:
1、B给A回信的时候,在信息后面附上了自己的数字证书
2、A收到B的回信以后,会取出附带的数字证书,并读取证书中的发布机构(Issuer),然后从操作系统的受信任证书机构列表中查找该证书办发机构的公钥,如果找不到,说明这个证书颁发机构是个不受信任的,B发过来的信息当然也是不安全的
3、使用上一步取到的证书颁发机构的公钥,解出数字证书,得到可能是B的用户信息和数字签名
4、A通过证书中指定的加密算法对可能是B的用户信息进行hash加密
5、加密后的结果和证书中解出的数字签名进行对比,如果相同,就说明这份用户信息确实是B的,也就是说用户信息中包含的公钥确实是B的
这样就验证了B身份的真实性。
下图很形象的表示了这个过程:

3.2.4证书发布中心(CA)的公钥的嵌套验证
这里有一个有趣的问题,用户A使用证书机构的公钥来验证用户B的数字证书,但如果A和B使用的证书认证中心(CA)不同怎么办呢?由于证书认证中心可以通过另外一个更高级别的认证中心对该证书机构的公钥颁发一个证书,这样形成了一个公钥证书的嵌套循环,该循环的终点就是根证书机构。根证书机构较少,其公钥可以通过安全的方式发布,如通过USB拷贝、书面文件当面移交。如此依赖,A就必须从B的CA的树形结构底部开始,从底层CA往上层CA查询,一直到找到共同的信任CA为止。
整个过程如下图所示:

3.2.5证书发布机构
3.2.5.1谁可以成为证书发布机构
到这里,你可能会想,那我们自己就不能发布证书吗?就一定要花钱去申请?
当然不是,我们自己也可以成立证书发布机构,但是需要通过一些安全认证等等,只是有点麻烦。另外,如果数字证书只是要在公司内部使用,公司可以自己给自己生成一个证书,在公司的所有机器上把这个证书设置为操作系统信任的证书发布机构的证书(这句话仔细看清楚,有点绕口),这样以后公司发布的证书在公司内部的所有机器上就可以通过验证了(在发布证书时,把这些证书的Issuer(发布机构)设置为我们自己的证书发布机构的证书的Subject(主题)就可以了)。但是这只限于内部应用,因为只有我们公司自己的机器上设置了信任我们自己这个所谓的证书发布机构,而其它机器上并没有事先信任我们这个证书发布机构,所以在其它机器上,我们发布的证书就无法通过安全验证。

我们自己可以去注册一家公司来专门给别人发布证书,但是很明显,我们自己的专门发布证书的公司是不会被那些国际上的权威机构认可的,人家怎么知道你是不是个狗屁皮包公司?因此微软(或其它操作系统提供商)在它的操作系统中,并不会信任我们这个证书发布机构,当应用程序在检查证书的合法信的时候,一看证书的发布机构并不是操作系统所信任的发布机构,就会抛出错误信息。也就是说windows操作系统中不会预先安装好我们这个证书发布机构的证书,不信任我们这个发布机构。

3.2.5.2不受信任的证书发布机构的危害
为什么一个证书发布机构受不受信任这么重要?我们举个例子。假设我们开了一个狗屁公司来为别人发布证书,并且我和微软有一腿,微软在他们的操作系统中把我设置为了受信任的证书发布机构。现在如果有个小公司叫hisunsray花了10块钱让我为他们公司申请了一个证书,并且公司慢慢壮大,证书的应用范围也越来越广。然后有个奸商的公司baidu想冒充hisunsray,于是给了我¥10000,让我为他们颁布一个证书,但是证书的名字(Subject)要写hisunsray,假如我为了这¥10000,真的把证书给了他们,那么他们以后就可以使用这个证书来冒充hisunsray了。
如果是一个优秀的证书发布机构,比如你要向他申请一个名字叫hisunsray的证书,它会让你提供很多资料证明你确实可以代表hisunsray这个公司,也就是说他回去核实你的身份。证书发布机构是要为他发布出的证书负法律责任的。