django的ajax403怎么解决?

为什么我用jQueryAjax调用后台方法，结果被403了

你好。403是资源不可用，或者你的url请求有误，导致服务器端相应不到，导致403，检查你的ajax请求路径，一般都是路径的问题.

jqueryajax是个很常用接口，而在请求时候，可能存在响应401的情况（身份认证过期或未登录），比较容易出现在混合应用上，如何进行身份认证，重发失败请求，还是值得注意的。

ajax请求有两种方式

1.回调

最常写的方式，成功失败处理以回调方式传入。

$.ajax({ajax参数...success:xxxxxxerror:xxxxxx});

2.Deferred方式

Deferred模式我在《js异步编程》有说明，ajax调用本身返回就是一个Deferred对象，成功失败回调不以参数传入。

$.ajax({ajax参数...}).then(function(res){//成功处理片段},function(err){//失败处理片段});

既然有这两种方式，那应对处理401的方式也是有两种。

401处理的两种方式

1.回调

这种方式的处理比较简单，在失败回调里面判断401，如果是则进行身份认证，成功重发请求。

functiongetXXXX(type,url,data,success,error){$.ajax({ajax参数...success:xxxxxxerror:function(xhr,textStatus,errorThrown){if(xhr.status==401){刷新身份认证方法(function(){getXXXX(type,url,data,success,error);});}else{//调用外部的errorerrorerror(xhr,textStatus,errorThrown);}}});}

2.Deferred方式

这种方式目前我找到的处理方式需要修改jquery源码。

//全局设置一个方法$.ajaxSetup({authError:function(callback){刷新身份认证方法(function(){callbackcallback();});}});//jquery2.1.4版本源码，大概是8261行//Success/Errorif(isSuccess){deferred.resolveWith(callbackContext,[success,statusText,jqXHR]);}else{if((jqXHR.status==401||jqXHR.status==403)callbackContext.authError){callbackContext.authError(function(){state=0;jqXHR.setRequestHeader("Authorization",XXXXXX);jqXHR.readyState=1;try{state=1;transport.send(requestHeaders,done);}catch(e){//Propagateexceptionaserrorifnotdoneif(state2){done(-1,e);//Simplyrethrowotherwise}else{throwe;}}});return;}else{deferred.rejectWith(callbackContext,[jqXHR,statusText,error]);}}

这里说下为什么不能像第一种方式那样进行请求。

有两个原因：

1.then这种链式写法，导致这请求的回调不是在参数里，而是在jQuery.Callbacks一个optionsCache全局变量里，我们无法在ajaxerror里拿到回调函数进行重发。

2.写在then里的回调触发一次就会被销毁，当触发了error时，回调执行后就销毁。

最后的处理方式就是在要触发error之前，拦截401的错误，重新进行身份认证，然后重置状态，重发请求。

以上这篇当jqueryajax遇上401请求的解决方法就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持脚本之家。

如今前端领域是MVVM框架的天下，组件库也层出不穷，但是，并没有一个知名的组件库提供ajax异常的成熟解决方案，所以今天我们就来研讨一下，如何尽量正确地处理异常。

从业务上简单说，凡是code不是200的，都是异常。这里code可以是HTTP状态码，也可以是响应体的code，就不细究了，反正本质没差别。然后，根据code的不同，又可以细分成401403404500等等。

如果你的后端伙伴以HTTP状态码表示404，以响应体code表示其他错误，而且你又无法劝说他们，那么你应在axios的*里把各种情况全考虑进去，比如：

超时很简单，axios也支持，设定超时阈值即可。超时跟无响应的区别是，超时意味着HTTP三次握手成功，但是得不到响应体，浏览器知道接口是存在的，但是响应体又在规定时间内没有拿到。无响应是根本无法HTTP握手，也就无法获知接口存在。

处理超时，通常做法是在*里重新请求一遍，还是超时的话就视为服务器错误。

得不到响应又分成2种，可能是网断了，也可能是服务器停机了。

苛刻地说，你应分辨这2种情况，并给出不同的提示，毕竟网断了，用户可以寻找别的联网方式，而服务器停机了就给个重连按钮，让用户有事没事的尝试重连一下。

关于解决方案，首先说，XHR对象无法区分到底断网还是服务器停机，axios对于2种情况都返回'NetworkError'。在得到这个反馈之后，你接下来可以有这2种解决办法：

你可以将改成其他服务器稳定且字节小的图片。或许你可以做一张几字节的图片，传到一个非常牛*的CDN上。

MDN手册：

它不支持IE，就算你不在乎这一点，那么它是不是一定准呢？对于需要登录的VPN网络，它是否准呢？我也不知道，总体说，它真的不是最佳的方案。我推荐用方案1。

很简单，分为3种：

通常，一个接口，只需要按照其中一种去处理即可，优先级就是上面书写顺序。

容器内错误提示肯定是内容区的接口出错才会出现。

处理方式：

局部报错比较容易理解，比如一个List的接口出错，那么，上策是应当给这个容器尽量撑高到有内容时的高度，然后居中给一个错误图标和错误描述。中策是不考虑有内容时候的高度，只让错误提示和错误描述撑起一定高度即可。都不算错。如果容器很小，比如就是一个3位数值，那么用一个-表示错误也可以。

页面整体报错稍微复杂，比如一个左右结构的内容管理系统，前置接口有userInfo接口、全局字典接口、全局路由接口等，这些接口与众不同的地方在于它们是基础接口，它们出错的话，网站干脆就不能用，页面骨架也是错乱的，这种情况下可以有2种解决办法：一是跳转到专门的5xx报错页面，页面*有错误图标、错误提示，以及“返回上一页”的按钮；二是用白板遮罩覆盖浏览器视口，居中放一个错误图标和错误文字以及“刷新页面”的按钮，本质是用一个fixed的遮罩压住浏览器全部面积。用哪种方案都可。所以你要做的是决定哪些接口属于全局报错，哪些接口属于局部报错，并做不同的处理。

报错内容：

根据ajax异常的分类，可能至少能分出3种：网络错误、服务器宕机、服务器错误。具体用什么图标和文字我就不多说了。

组件化：

容器内报错应尽量组件化。该放返回上一页或刷新按钮的，一定要放按钮。

排他性：

只要做了容器内报错，就不要做另外报错了。这也说明了一点，就是在axios*里弹toast或者modal是愚蠢的方案，我在别的文章也提到过这种观点。不做容器内报错的情况，才应该考虑其他3种情况。

什么样的场景下使用容器隐藏？

比如页面有一个角落显示你的粉丝数、关注数、评论量……。如果有获取到数据，则让这个容器出现，没有的话，则容器就保持隐藏。这一类场景往往应用于非主要内容，比如侧边栏的小内容块。

由于这只适用于非主要内容，那么主要内容也会有它自己的报错，所以，你不必担心用户看不到“网络出错”这类错误提示。

先简单对比一下toast和modal。

很简单，toast就是轻提示，不需要手动关闭，modal就是重提示，需要手动关闭。采用哪个，只要站在用户角度思考问题就好了。比如有人说，异常应当用重提示。可以这么绝对化么？不可以。比如你在某个页面点赞，提示你“您已经点过赞了”，这用重提示吗？肯定toast就够了。同样的，成功提示一定用轻提示吗？比如提示“感谢参与，工作人员将在3~5个工作日内联系你”，这么长，能toast？能一闪而过？

什么接口适用弹出提示？简单说，只要跟UI显示不相干的，都最好是使用弹出提示。比如这几种场景：

先说上传数据断网之类的错误，通常用modal，因为modal能够拦截用户动作，避免重复上传，而且，还能给用户足够的时间让用户看清楚出错原因，避免无谓的重试。

然后说数据内容错误，无论是表单提交，还是点个赞，错误提示一般用toast，毕竟用户可能只是不小心填错的，看一眼然后赶紧改正就好了。

最后说401错误，有2种做法，一是用modal，因为一般要强制用户转到登录页，但是转之前也得让用户看明白为什么要转，所以可以先modal提示，点击确定就跳转到登录页；二是用toast，但是需要先跳转，然后在登录页上提示toast“请先登录”。

警告条

警告条是可关闭的、永久生命的、又不妨碍用户继续操作的弹出组件，一般在页面顶部，或者在用户操作区域的附近。什么场景用警告条？

比如的MD编辑器，你只要输入，就会自动给服务器发送数据，频率很快，有时候因为网络或者服务器的问题，会出现保存失败的可能性，这时候就会在页面顶部出现一个比较长时间的警告条，告诉你保存失败，但你依然可以继续写，什么时候网络正常了，什么时候toast才会自动消失，当然你也可以手动关闭它。

总之，toast、modal、警告条究竟什么场合使用，要根据产品、业务具体而定，要注意优先使用容器内报错和容器隐藏。

结语：以上就是首席CTO笔记为大家整理的关于django的ajax403怎么解决的全部内容了，感谢您花时间阅读本站内容，希望对您有所帮助，更多关于django的ajax403怎么解决的相关内容别忘了在本站进行查找喔。