⑴ 求大神讲讲web安全,nodejs怎么防止跨域攻击和sql注入
是CSRF(Cross-site request forgery) 不是你写的那个!
跨域不用担心.主流浏览器都会帮你做防御的. 问题不大,主要是你自己别给其他域的权限即可.非必要的话,以最小权限原则.
xss主要就是过滤输入输出.如果业务很多,还是找人审计代码吧.或者用比较成熟的模块.CSRF的话,1,验证来源 2加随机token之类的.
sqli主要还是过滤输入的地方.过滤/转义关键字比如select,and,or等等(有专门的防注入模块).觉得怕麻烦的话.用那些云主机的防御功能.再加个cdn基本就没事了.(对于一般的反射型跨站也适用)
⑵ web.config 跨域问题
一、认识Web.config文件
Web.config文件是一个XML文本文件,它用来储存 ASP.NET Web 应用程序的配置信息(如最常用的设置ASP.NET Web 应用程序的身份验证方式),它可以出现在应用程序的每一个目录中。当你通过VB.NET新建一个Web应用程序后,默认情况下会在根目录自动创建一个默认的
Web.config文件,包括默认的配置设置,所有的子目录都继承它的配置设置。如果你想修改子目录的配置设置,你可以在该子目录下新建一个Web.config文件。它可以提供除从父目录继承的配置信息以外的配置信息,也可以重写或修改父目录中定义的设置。
在运行时对Web.config文件的修改不需要重启服务就可以生效(注:<processModel> 节例外)。当然Web.config文件是可以扩展的。你可以自定义新配置参数并编写配置节处理程序以对它们进行处理。
二、web.config配置文件(默认的配置设置)以下所有的代码都应该位于
<configuration>
<system.web>
和
</system.web>
</configuration>
之间,出于学习的目的下面的示例都省略了这段XML标记
1、<authentication> 节
作用:配置 ASP.NET 身份验证支持(为Windows、Forms、PassPort、None四种)。该元素只能在计算机、站点或应用程序级别声明。<authentication> 元素必需与<authorization> 节配合使用。
示例:
以下示例为基于窗体(Forms)的身份验证配置站点,当没有登陆的用户访问需要身份验证的网页,网页自动跳转到登陆网页。
<authentication mode="Forms" >
<forms loginUrl="logon.aspx" name=".FormsAuthCookie"/>
</authentication>
其中元素loginUrl表示登陆网页的名称,name表示Cookie名称
2、<authorization> 节
作用:控制对 URL 资源的客户端访问(如允许匿名用户访问)。此元素可以在任何级别(计算机、站点、应用程序、子目录或页)上声明。必需与<authentication> 节配合使用。
示例:以下示例禁止匿名用户的访问
<authorization>
<deny users="?"/>
</authorization>
注:你可以使用user.identity.name来获取已经过验证的当前的用户名;可以使用
web.Security.FormsAuthentication.RedirectFromLoginPage方法将已验证的用户重定向到用户刚才请求的页面.具体的实例请参考:
Forms验证 http://www.fanvb.net/websample/dataauth.aspx
3、<compilation>节
作用:配置 ASP.NET 使用的所有编译设置。默认的debug属性为“True”.在程序编译完成交付使用之后应将其设为True(Web.config文件中有详细说明,此处省略示例)
4、<customErrors>
作用:为 ASP.NET 应用程序提供有关自定义错误信息的信息。它不适用于 XML Web services 中发生的错误。
示例:当发生错误时,将网页跳转到自定义的错误页面。
<customErrors defaultRedirect="ErrorPage.aspx" mode="RemoteOnly">
</customErrors>
其中元素defaultRedirect表示自定义的错误网页的名称。mode元素表示:对不在本地 Web 服务器上运行的用户显示自定义(友好的)信息。
5、<httpRuntime>节
作用:配置 ASP.NET HTTP 运行库设置。该节可以在计算机、站点、应用程序和子目录级别声明。
示例:控制用户上传文件最大为4M,最长时间为60秒,最多请求数为100
<httpRuntime maxRequestLength="4096" executionTimeout="60" appRequestQueueLimit="100"/>
6、 <pages>
作用:标识特定于页的配置设置(如是否启用会话状态、视图状态,是否检测用户的输入等)。<pages>可以在计算机、站点、应用程序和子目录级别声明。
示例:不检测用户在浏览器输入的内容中是否存在潜在的危险数据(注:该项默认是检测,如果你使用了不检测,一要对用户的输入进行编码或验证),在从客户端回发页时将检查加密的视图状态,以验证视图状态是否已在客户端被篡改。(注:该项默认是不验证)
<pages buffer="true" enableViewStateMac="true" validateRequest="false"/>
7、<sessionState>
作用:为当前应用程序配置会话状态设置(如设置是否启用会话状态,会话状态保存位置)。
示例:
<sessionState mode="InProc" cookieless="true" timeout="20"/>
</sessionState>
注:
mode="InProc"表示:在本地储存会话状态(你也可以选择储存在远程服务器或SAL服务器中或不启用会话状态)
cookieless="true"表示:如果用户浏览器不支持Cookie时启用会话状态(默认为False)
timeout="20"表示:会话可以处于空闲状态的分钟数
8、<trace>
作用:配置 ASP.NET 跟踪服务,主要用来程序测试判断哪里出错。
示例:以下为Web.config中的默认配置:
<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
注:
enabled="false"表示不启用跟踪;requestLimit="10"表示指定在服务器上存储的跟踪请求的数目
pageOutput="false"表示只能通过跟踪实用工具访问跟踪输出;
traceMode="SortByTime"表示以处理跟踪的顺序来显示跟踪信息
localOnly="true" 表示跟踪查看器 (trace.axd) 只用于宿主 Web 服务器
三、自定义Web.config文件配置节
自定义Web.config文件配置节过程分为两步。
一是在在配置文件顶部 <configSections> 和 </configSections>标记之间声明配置节的名称和处理该节中配置数据的 .NET Framework 类的名称。
二是在 <configSections> 区域之后为声明的节做实际的配置设置。
示例:创建一个节存储数据库连接字符串
<configuration>
<configSections>
<section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</configSections>
<appSettings>
<add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/>
</appSettings>
<system.web>
......
</system.web>
</configuration>
四、访问Web.config文件
你可以通过使用ConfigurationSettings.AppSettings 静态字符串集合来访问 Web.config 文件示例:获取上面例子中建立的连接字符串。
Dim sconstr As String = ConfigurationSettings.AppSettings("SconStr")
Dim scon = New SqlConnection(sconstr)
⑶ 如何用webpack解决跨域问题
汇编主要是要了解CPU指令及用法,常说的是PC机的x86汇编,指令是x86的复杂指令集。
arm汇编是arm的精简指令集,比x86容易学,程序格式倒是和x86汇编差不多。
C语言ARM的和x86的差不多,除了对硬件寄存器操作不同,其它语法和流程都一样。
arm汇编程序每一行是指定arm core执行一条指令,每条指令都是硬件相关。
如:LDR R3, #1 ;用LDR指令将数值1放入R3寄存器准备参与运算
C语言与arm指令无关,只与逻辑运算有关,指定硬件地址的操作才与硬件相关;
如果用arm编译器来编译,每行可能编译出1到多条arm指令。
⑷ 手机APP和web服务端 跨域问题
跨域问题来源于JavaScript的同源策略,即只有 协议+主机名+端口号 (如存在)相同,则允许相互访问。也就是说JavaScript只能访问和操作自己域下的资源,不能访问和操作其他域下的资源。
在以前,前端和后端混杂在一起, 比如JavaScript直接调用同系统里面的一个Httphandler,就不存在跨域的问题,但是随着现代的这种多种客户端的流行,比如一个应用通常会有Web端,App端,以及WebApp端,各种客户端通常会使用同一套的后台处理逻辑,即API, 前后端分离的开发策略流行起来,前端只关注展现,通常使用JavaScript,后端处理逻辑和数据通常使用WebService来提供json数据。一般的前端页面和后端的WebService API通常部署在不同的服务器或者域名上。这样,通过ajax请求WebService的时候,就会出现同源策略的问题。
需要说明的是,同源策略是JavaScript里面的限制,其他的编程语言,比如在C#,Java或者iOS等其他语言中是可以调用外部的WebService,也就是说,如果开发Native应用,是不存在这个问题的,但是如果开发Web或者Html5如WebApp,通常使用JavaScript ajax对WebService发起请求然后解析返回的值,这样就可能存在跨域的问题。
一般的,很容易想到,将外部的资源搬到同一个域上就能解决同源策略的限制的。即在Web网站上同时开发一个Http服务端页面,所有JavaScript的请求都发到这个页面上来,这个页面在内部使用其他语言去调用外部的WebService。即添加一个代理层。这种方式可以解决问题,但是不够直接和高效。
目前,比较常见的跨域解决方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解决方案需要客户端和服务端配合如JSOP,一些则只需要服务端配合处理比如CORS。下面分别介绍这两种跨域方案,以及服务端WebService如何支持这两种跨域方案。
JSONP以及WebService的支持
同源策略下,某个服务器是无法获取到服务器以外的数据,但是html里面的img,iframe和script等标签是个例外,这些标签可以通过src属性请求到其他服务器上的数据。而JSONP就是通过script节点src调用跨域的请求。
当我们向服务器提交一个JSONP的请求时,我们给服务传了一个特殊的参数,告诉服务端要对结果特殊处理一下。这样服务端返回的数据就会进行一点包装,客户端就可以处理。
举个例子,服务端和客户端约定要传一个名为callback的参数来使用JSONP功能。比如请求的参数如下:
http://www.example.net/sample.aspx?callback=mycallback
如果没有后面的callback参数,即不使用JSONP的模式,该服务的返回结果可能是一个单纯的json字符串,比如:
{ foo : 'bar' }
如果和服务端约定jsonp格式,那么服务端就会处理callback的参数,将返回结果进行一下处理,比如处理成:
mycallback({ foo : 'bar' })
可以看到,这其实是一个函数调用,比如可以实现在页面定义一个名为mycallback的回调函数:
mycallback = function(data)
{
alert(data.foo);
};
现在,请求的返回值回去触发回调函数,这样就完了了跨域请求。
如果使用ServiceStack创建WebService的话,支持Jsonp方式的调用很简单,只需要在AppHost的Configure函数里面注册一下对响应结果进行过滤处理即可。
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
ResponseFilters.Add((req, res, dto) =>
{
var func = req.QueryString.Get("callback");
if (!func.isNullOrEmpty())
{
res.AddHeader("Content-Type", ContentType.Html);
res.Write("<script type='text/javascript'>{0}({1});</script>"
.FormatWith(func, dto.ToJson()));
res.Close();
}
});
}
JSONP跨域方式比较方便,也支持各种较老的浏览器,但是缺点很明显,他只支持GET的方式提交,不支持其他Post的提交,Get方式对请求的参数长度有限制,在有些情况下可能不满足要求。所以下面就介绍一下CORS的跨域解决方案。
CORS跨域及WebService的支持
先来看一个例子,我们新建一个基本的html页面,在里面编写一个简单的是否支持跨域的小脚本,如下:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>AJAX跨域请求测试</title>
</head>
<body>
<input type='button' value='开始测试' onclick='crossDomainRequest()' />
<div id="content"></div>
<script type="text/javascript">
//<![CDATA[
var xhr = new XMLHttpRequest();
var url = 'http://localhost:8078/json/ShopUserLogin';
function crossDomainRequest() {
document.getElementById("content").innerHTML = "开始……";
if (xhr) {
xhr.open('POST', url, true);
xhr.onreadystatechange = handler;
xhr.send();
} else {
document.getElementById("content").innerHTML = "不能创建 XMLHttpRequest";
}
}
function handler(evtXHR) {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
var response = xhr.responseText;
document.getElementById("content").innerHTML = "结果:" + response;
} else {
document.getElementById("content").innerHTML = "不允许跨域请求。";
}
}
else {
document.getElementById("content").innerHTML += "<br/>执行状态 readyState:" + xhr.readyState;
}
}
//]]>
</script>
</body>
</html>
然后保存为本地html文件,可以看到,这个脚本中,对本地的服务http://localhost:1337/json/Hello 发起了一个请求, 如果使用chrome 直接打开,会看到输出的结果,不允许跨域请求。 在javascript控制台程序中同样可以看到错误提示:
那么如果在返回响应头header中注入Access-Control-Allow-Origin,这样浏览器检测到header中的Access-Control-Allow-Origin,则就可以跨域操作了。
同样,如果使用ServcieStack,在很多地方可以支持CORS的跨域方式。最简单的还是在AppHost的Configure函数里面直接写入:
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
this.AddPlugin(new CorsFeature());
}
这样就可以了,相当于使用默认的CORS配置:
CorsFeature(allowedOrigins:"*",
allowedMethods:"GET, POST, PUT, DELETE, OPTIONS",
allowedHeaders:"Content-Type",
allowCredentials:false);
如果仅仅允许GET和POST的请求支持CORS,则只需要改为:
Plugins.Add(new CorsFeature(allowedMethods: "GET, POST"));
当然也可以在AppHost的Config里面设置全局的CORS,如下:
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
base.SetConfig(new EndpointHostConfig
{
GlobalResponseHeaders = {
{ "Access-Control-Allow-Origin", "*" },
{ "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS" },
{ "Access-Control-Allow-Headers", "Content-Type" },
},
});
}
现在运行WebService,使用postman或者Chrome调用这个请求,可以看到返回的值头文件中,已经加上了响应头,并且可以正常显示返回结果了:
CORS使用起来简单,不需要客户端的额外处理,而且支持Post的方式提交请求,但是CORS的唯一一个缺点是对客户端的浏览器版本有要求,支持CORS的浏览器机器版本如下:
总结
本文介绍了JavaScript中的跨域基本概念和产生的原因,以及如何解决跨域的两种方法,一种是JSONP 一种是 CORS,在客户端Javascript调用服务端接口的时候,如果需要支持跨域的话,需要服务端支持。JSONP的方式就是服务端对返回的值进行回调函数包装,他的优点是支持众多的浏览器, 缺点是仅支持Get的方式对服务端请求。另一种主流的跨域方案是CORS,他仅需要服务端在返回数据的时候在相应头中加入标识信息。这种方式非常简便。唯一的缺点是需要浏览器的支持,一些较老的浏览器可能不支持CORS特性。
跨域支持是创建WebService时应该考虑的一个功能点,希望本文对您在这边面有所帮助,文中是使用ServiceStack来演示跨域支持的,如果您用的WCF的话,知道跨域原理的前提下,实现跨域应该不难。
参考资料:
https://github.com/ServiceStack/ServiceStack/wiki/Customize-HTTP-Responses
https://github.com/ServiceStack/ServiceStack/wiki/Request-and-response-filters
http://stackoverflow.com/questions/8211930/servicestack-rest-api-and-cors
http://stackoverflow.com/questions/15224038/rename-callback-parameter-for-jsonp
⑸ 跨域是指什么,因为什么引起的有哪些解决方案web前端知识
广义跨域就是指跨域访问,简单来说就是 A 网站的 javascript 代码试图访问 B 网站,包括提交内容和获取内容。由于安全原因,跨域访问是被各大浏览器所默认禁止的。
当一个域与其他域建立了信任关系后,2个域之间不但可以按需要相互进行管理,还可以跨网分配文件和打印机等设备资源,使不同的域之间实现网络资源的共享与管理。这就形成了“跨域”。
⑹ 如何防止web攻击
SQL注入攻击(SQL Injection)
攻击者把SQL命令插入到Web表单的输入域或页面请求的字符串,欺骗服务器执行恶意的SQL命令。在某些表单中,用户输入的内容直接用来构造(或者影响)动态SQL命令,或作为存储过程的输入参数,这类表单特别容易受到SQL注入式攻击。
常见的SQL注入式攻击过程类如:
1.某个Web应用有一个登录页面,这个登录页面控制着用户是否有权访问应用,它要求用户输入一个名称和密码;
2.登录页面中输入的内容将直接用来构造动态的SQL命令,或者直接用作存储过程的参数;
例如:
$query = 'SELECT * from Users WHERE login = ' . $username . ' AND password = ' . $password;
3.攻击者在用户名字和密码输入框中输入'或'1'='1之类的内容;
4.用户输入的内容提交给服务器之后,服务器运行上面的代码构造出查询用户的SQL命令,但由于攻击者输入的内容非常特殊,所以最后得到的SQL命令变成:
SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1';
5.服务器执行查询或存储过程,将用户输入的身份信息和服务器中保存的身份信息进行对比;
6.由于SQL命令实际上已被注入式攻击修改,已经不能真正验证用户身份,所以系统会错误地授权给攻击者。
如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询,他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能,欺骗系统授予访问权限。
系统环境不同,攻击者可能造成的损害也不同,这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限,攻击者就可能对数据库的表执行各种他想要做的操作,包括添加、删除或更新数据,甚至可能直接删除表
防范方法:
1.检查变量数据类型和格式
2.过滤特殊符号
3.绑定变量,使用预编译语句
跨网站脚本攻击(Cross Site scripting, XSS)
攻击者将恶意代码注入到网页上,其他用户在加载网页时就会执行代码,攻击者可能得到包括但不限于更高的权限(如执行一些操作)、私密网页内容、会话和cookie等各种内容。这些恶意代码通常是javascript、HTML以及其他客户端脚本语言。
例如:
<?php
echo "欢迎您,".$_GET['name'];
常用的攻击手段有:
盗用cookie,获取敏感信息;
利用iframe、frame、xmlHttpRequest或上述Flash等方式,以(被攻击)用户的身份执行一些管理动作,或执行一些一般的如发微博、加好友、发私信等操作;
利用可被攻击的域受到其他域信任的特点,以受信任来源的身份请求一些平时不允许的操作,如进行不当的投票活动;
在访问量极大的一些页面上的XSS可以攻击一些小型网站,实现DDoS攻击的效果。
防范方法:使用htmlspecialchars函数将特殊字符转换成HTML编码,过滤输出的变量
跨网站请求伪造攻击(Cross Site Request Forgeries, CSRF)
攻击者伪造目标用户的HTTP请求,然后此请求发送到有CSRF漏洞的网站,网站执行此请求后,引发跨站请求伪造攻击。攻击者利用隐蔽的HTTP连接,让目标用户在不注意的情况下单击这个链接,由于是用户自己点击的,而他又是合法用户拥有合法权限,所以目标用户能够在网站内执行特定的HTTP链接,从而达到攻击者的目的。
它与XSS的攻击方法不同,XSS利用漏洞影响站点内的用户,攻击目标是同一站点内的用户者,而CSRF 通过伪装成受害用户发送恶意请求来影响Web系统中受害用户的利益。
例如:
某个购物网站购买商品时,采用shop.com/buy.php?item=watch&num=100
item参数确定要购买什么物品,num参数确定要购买数量,如果攻击者以隐藏的方式发送给目标用户链接那么如果目标用户不小心访问以后,购买的数量就成了100个
防范方法:
1、检查网页的来源
2、检查内置的隐藏变量
3、使用POST,不要使用GET,处理变量也不要直接使用$_REQUEST
Session固定攻击(Session Fixation)
这种攻击方式的核心要点就是让合法用户使用攻击者预先设定的session id来访问被攻击的应用程序,一旦用户的会话ID被成功固定,攻击者就可以通过此session id来冒充用户访问应用程序。
例如:
1.攻击者访问网站bank.com,获取他自己的session id,如:SID=123;
2.攻击者给目标用户发送链接,并带上自己的session id,如:bank.com/?SID=123;
3.目标用户点击了bank.com/?SID=123,像往常一样,输入自己的用户名、密码登录到网站;
4.由于服务器的session id不改变,现在攻击者点击bank.com/?SID=123,他就拥有了目标用户的身份,可以为所欲为了。
防范方法:
1.定期更改session id
session_regenerate_id(TRUE);//删除旧的session文件,每次都会产生一个新的session id。默认false,保留旧的session
2.更改session的名称
session的默认名称是PHPSESSID,此变量会保存在cookie中,如果攻击者不抓包分析,就不能猜到这个名称,阻挡部分攻击[code]session_name("mysessionid");
复制代码
3.关闭透明化session id
透明化session id指当浏览器中的http请求没有使用cookie来制定session id时,sessioin id使用链接来传递
int_set("session.use_trans_sid", 0);
复制代码
4.只从cookie检查session id
int_set("session.use_cookies", 1);//表示使用cookies存放session id
int_set("session.use_only_cookies", 1);//表示只使用cookies存放session id
复制代码
5.使用URL传递隐藏参数
$sid = md5(uniqid(rand()), TRUE));
$_SESSION["sid"] = $sid;//攻击者虽然能获取session数据,但是无法得知$sid的值,只要检查sid的值,就可以确认当前页面是否是web程序自己调用的
Session劫持攻击(Session Hijacking)
会话劫持是指攻击者利用各种手段来获取目标用户的session id。一旦获取到session id,那么攻击者可以利用目标用户的身份来登录网站,获取目标用户的操作权限。
攻击者获取目标用户session id的方法:
1.暴力破解:尝试各种session id,直到破解为止;
2.计算:如果session id使用非随机的方式产生,那么就有可能计算出来;
3.窃取:使用网络截获,xss攻击等方法获得
防范方法:
1.定期更改session id
2.更改session的名称
3.关闭透明化session id
4.设置HttpOnly。通过设置Cookie的HttpOnly为true,可以防止客户端脚本访问这个Cookie,从而有效的防止XSS攻击。
文件上传漏洞攻击(File Upload Attack)
文件上传漏洞指攻击者利用程序缺陷绕过系统对文件的验证与处理策略将恶意代码上传到服务器并获得执行服务器端命令的能力。
常用的攻击手段有:
上传Web脚本代码,Web容器解释执行上传的恶意脚本;
上传Flash跨域策略文件crossdomain.xml,修改访问权限(其他策略文件利用方式类似);
上传病毒、木马文件,诱骗用户和管理员下载执行;
上传包含脚本的图片,某些浏览器的低级版本会执行该脚本,用于钓鱼和欺诈。
总的来说,利用的上传文件要么具备可执行能力(恶意代码),要么具备影响服务器行为的能力(配置文件)。
防范方法:
1.文件上传的目录设置为不可执行;
2.判断文件类型,设置白名单。对于图片的处理,可以使用压缩函数或者resize函数,在处理图片的同时破坏图片中可能包含的HTML代码;
3.使用随机数改写文件名和文件路径:一个是上传后无法访问;再来就是像shell.php.rar.rar和crossdomain.xml这种文件,都将因为重命名而无法攻击;
4.单独设置文件服务器的域名:由于浏览器同源策略的关系,一系列客户端攻击将失效,比如上传crossdomain.xml、上传包含javascript的XSS利用等问题将得到解决。
⑺ 什么是跨域,有什么攻击,如何防止攻击
跨域是指跨区域,后面敏感字 有规定不能使用,请参考视频
⑻ web跨域问题(java) 跨域请求
Socket处理HTTP请求太搞了吧?
用Restful Service做吧,如果需要安全认证,可以用HTTP基本认证方式。
⑼ nginx 怎么解决webservice跨域
下载Nginx
网络搜索Nginx,找到官网下载,如果是Linux系统,直接输入下面命令即可下载
wget http://nginx.org/download/nginx-1.8.1.tar.gz
我们这里使用的是1.8.1版本
安装Nginx
使用tar xvf nginx-1.8.1.tar.gz命令,解压刚下载文件,得到一个nginx-1.8.1目录。
进入nginx-1.8.1,执行./configure --prefix=/usr/local/nginx命令,表示将nginx安装到/usr/local/nginx目录下。
在使用make & make install命令正式安装nginx,完成后就可以在/usr/local/nginx目录下看到已经装好的nginx了。
如果安装权限不够,请使用sudo make install命令。
模拟跨域错误
启动Nginx,并在Nginx的html目录下,编写一个ajax.html页面,在里面通过ajax方式请求taobao的ip地址查询api。
在浏览器中访问http://127.0.0.1/ajax.html,然后按F12即可在Console里面看到跨域错误。
下面我们就通过Nginx来解决这种跨域问题。
⑽ 前端web开发html如何避免js的跨域访问
前端web开发html避免js的跨域访问的方法是后台服务端做域配置兼容处理。
1、在server端请求过滤的时候加入以下控制:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
Access-Control-Allow-Origin这个属性配置成*就表示接受任何域过来的请求
2.ajax中请求如下:
$.ajax({
xhrFields: {
withCredentials: true
},
data:{ my: 'a' },
url: 'http://MyApp/Page', 这里是跨域访问
type: 'POST'
})