技术同学对自身的成长也是有强烈需求的，因此在两者都能满足业务需求时，我们更希望能应用一些较新的技术，折腾一些未知的东西，因此我们决定选用qiankun。 项目架构 后台系统一般都是上下或左右的布局。...从开发者的角度看，整个系统可能有N个子应用，如果启动整个系统可能会很慢很卡，而产品的某个需求可能只涉及到其中一个子应用，因此开发时只需启动涉及到的子应用即可，独立启动专注开发，因此是很有必要支持子应用的独立开发的...考虑到并不是所有人都会使用该聚合仓库，子仓库独立开发时往往不会主动同步到聚合库，使用聚合库的同学就得经常做同步的操作，比较耗时耗力，不算特别完美。 所以第三种方案比较符合笔者目前团队的情况。...在本地dev开发时是完全正常的，这个问题是部署后在首次打开页面才会出现的，F5刷新后又会正常，只能在清掉缓存后复现一次。这个bug困扰了几天。...把这个讲出来，是想说遇到bug时还是要先检查一下自己，别轻易就去质疑别人。 最后 本文从开始搭建到部署非常完整地分享了整个架构搭建的一些思路和实践，希望能对大家有所帮助。
本套课程将带领你使用Django和国内免费的大模型API（课程中使用的是讯飞星火大模型）搭建一个属于自己的AI网站，从基础知识的掌握到项目的部署，让你能够全方位了解AI技术在实际应用中的操作和实现。...通过这些学习，你将能够利用Docker高效地管理和部署你的应用。了解云服务器的购买与使用为了能够将我们开发的AI网站部署到互联网上，我们需要购买和配置云服务器。...服务器部署服务器环境搭建在完成AI功能的开发之后，我们需要将应用部署到云服务器上。课程将介绍如何在服务器上搭建运行环境，包括操作系统的配置、必要软件的安装等内容。...通过这些操作，你将能够为你的应用提供稳定的运行环境。代码部署接下来，我们将介绍如何将代码部署到服务器上。包括代码的上传、配置文件的修改、数据库的迁移等内容。...通过这些操作，你将能够将你的AI网站顺利运行在服务器上，提供给用户使用。网站测试在代码部署完成后，我们需要对网站进行测试，确保所有功能都能够正常运行。
最近我遭遇了一个奇怪的问题。使用Azure DevOps配置CI/CD管线，自动部署到Azure App Service以后，.NET Core的网站竟然会启动失败。我们来看看如何解决这个问题。 ?...发现执行的代码路径竟然不是在App Service应有的网站根目录！于是我的代码找不到依赖项，就爆了。 怎么回事 我尝试了手动从VS部署，也是爆的。在Azure DevOps重新部署，也是爆的。...但是我再次用CI/CD管线部署以后，又产生了大爆炸。细心的我，保留了网站运行正常时候的配置信息，与爆炸以后的配置对比发现，是多了这么一个设置： ?...与传统部署的差别就是，传统部署会把新文件覆盖到wwwroot目录，也就是我们的网站根目录，而用了RUN_FROM_PACKAGE的话，网站执行的时候会指向一个zip文件，压缩包的内容会映射到wwwroot...恢复网站运行 想要临时恢复网站运行，非常简单，只要将WEBSITE_RUN_FROM_PACKAGE这个设置整个删除，重启网站，就可以恢复到部署前的良好版本。
但是当部署多个后台服务时，我们的session就会出现问题，看看下面的图， [image-20200602093858501.png] 假如用户登录的请求，分配到了后台服务1，后台服务1的session...总体归纳为： 后端设置CORS允许跨域的域名，并且withCredentials设置为true； 前端在向后端发送请求时，也需要设置withCredentials = true; 这样，我们的Cookie...在前端JWT不会自动存储到Cookie中，前端开发人员要处理JWT的存储问题，比如LocalStorage 再次发起请求，JWT不会自动放到请求头中，需前端同学手动设置 后端从请求头中取出JWT，验签通过后...我们在后台部署集群的时候，根本不用care这个问题。 CORS Cookie的跨域受到同源策略的保护，不经过特殊的设置，是不能够跨域的。那么JWT呢？...JWT在前端存储在A网站的域下，B在访问A网站时，是拿不到A网站的JWT的，那么也不可能在请求头中设置JWT，A网站的后台拿不到JWT，也不会做其他操作。所以，JWT可以很好的防止CSRF攻击。
分布式会话 上面的示例，我们的后台服务只有一个，一个服务往往很难支撑服务，为了保障可靠性，最少都是部署两个后台服务。但是当部署多个后台服务时，我们的session就会出现问题，看看下面的图， ?...总体归纳为： 后端设置CORS允许跨域的域名，并且withCredentials设置为true； 前端在向后端发送请求时，也需要设置withCredentials = true; 这样，我们的Cookie...在前端JWT不会自动存储到Cookie中，前端开发人员要处理JWT的存储问题，比如LocalStorage 再次发起请求，JWT不会自动放到请求头中，需前端同学手动设置 后端从请求头中取出JWT，验签通过后...无论请求被分配到哪一个后台服务中，登录状态和用户id都是从JWT中取出来的，不会出现分布式会话的问题。我们在后台部署集群的时候，根本不用care这个问题。...JWT在前端存储在A网站的域下，B在访问A网站时，是拿不到A网站的JWT的，那么也不可能在请求头中设置JWT，A网站的后台拿不到JWT，也不会做其他操作。所以，JWT可以很好的防止CSRF攻击。
如今“前后端分离”的设计思想已经非常普及，所以一旦静态资源和后台应用部署在不同服务器上并采用不同域名，那么，必然会遇到“浏览器同源策略”的限制，也必然，需要前后台一起合作解决跨域问题。 1....那么，在“同源策略”限制下，a.com网站无法获取api.b.com下的cookie，也无法向api.b.com发送ajax请求。 2....其实，通过src调用api都是GET方式，类似请求资源文件，必须明确，从Web页面产生的文件请求都会带上cookie。...下面要重点提到的是，CORS下，前端如何携带cookies?...这时，request请求中可以携带的cookies，不仅仅有本域下的cookies，还包括跨域服务器下设置的cookies（注意：跨域服务器下的cookies，是无法通过JS代码document.cookie
在AJAX出现时，那时的服务端还是很古老的那一批，因此完全没有考虑到AJAX出现后，前端请求方式会变得异常复杂，造成以前的安全策略已经无法满足要求了，导致大批的后台安全漏洞曝光。。。...譬如假设上图中第4部分的请求由AJAX发起，假设网站A已经允许了Access-Control-Allow-Origin: *，由于网站B与网站A是不同域名，所以存在跨域，根据同源策略，请求时根本就无法携带...1. cookie劫持 同样，页面中有一个评论输入，输入后会，因为后台的漏洞，没有过滤特殊字符，会直接明文保存到数据库中，然后展示到网页时直接展示明文数据，那么如下 <%@ page language=...上述的介绍更多的是从造成的后果来看，但其实如果从攻击手动来看的话可以分为几大类型：反射型XSS攻击（直接通过URL注入，而且很多浏览器都自带防御），存储型XSS攻击（存储到DB后读取时注入），还有一个DOM-Based...输出进行编码，和输入过滤类似，不过是从输出上着手，数据输出到页面时，经过HtmlEncoder等工具编码，这样就不会存在直接输出可执行的脚本了 cookie设置http-only，这样用脚本就无法获取cookie
DOM型：不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题，一次性，也属于反射型 基础再巩固： XSS是通过向 存在XSS漏洞的网站上注入了恶意代码，用户浏览并访问了该网站从而引发的一种漏洞...用户恶意输入数据--->服务器存储在数据库--->用户访问--->浏览器解析执行 DOM型XSS：纯前端漏洞，服务器端无法防御，前端通过 JS 操作DOM 中节点（遍历，获取，修改对应的节点，对象，值）...XSS下攻击者可以将脚本注入到后台存储起来，构成更加持久的危害。...id从6开始，正常从1开始 反射型XSS（post）获取用户cookie 1 首先登录账号(admin/123456) 2 随便输入内容，点击提交，发现输入的内容直接拼接到界面中 看到这里你是不是觉得这个不是跟...get类型一样嘛，对的，原理是一样的，但是，提交方式是以表单方式提交的，这时就无法将恶意代码嵌入到URL中发给目标。
用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。...Set-Cookie 设置 HttpOnly 属性 禁止 JavaScript 读取某些敏感 Cookie，攻击者即使完成 XSS 注入后也无法窃取此 Cookie。...3.3 防御措施 CSRF 通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对 CSRF 的防护能力来提升安全性。...因此，为了安全起见，前端在访问后台接口时，可以把 Token 放到如下三个地方： URL Query Header Request Body （4）双重 Cookie 验证。...在一次客户端与服务端的请求过程中，从请求方到接收方中间要经过很多路由器和交换机，黑客可以在中途截获请求的数据，篡改请求内容后再发往服务端，比如中间人攻击。
后端可以收到请求并返回数据，但是前端无法收到数据。...当我们访问了一个恶意网站 如果没有同源策略 那么这个网站就能通过js 访问document.cookie 得到用户关于的各个网站的sessionID 其中可能有银行网站 等等。...（详见《详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocke》一文中的第3节“三、JSONP”） 6.2 使用 JSONP，服务器后台代码需要改动吗？...▲ jquery动态生成script脚本 6.4 JSONP的优缺点 JSONP的优点：部署时不需要应用服务器去进行额外的配置，跟普通的非跨域系统部署一模一样，没有特别的要求。...”: “*“，但是这样的星号设置不能满足带 Cookie 的跨域请求。
当单台服务器由于性能不足无法处理众多用户的访问时，就要考虑用多台服务器来提供服务，实现的方式就是负载均衡。...，但是考虑到客户端可能有上述不利于源地址会话保持的环境，采用Cookie会话保持是一个更好的方式。...Cookie会话保持会把负载均衡设备选择的Server信息保存在Cookie中发送到客户端，客户端持续访问时，会把该Cookie带来，负载均衡器通过分析Cookie把会话保持到之前选定的服务器。...由于现在的浏览器对Cookie都有一定默认的安全设置，有些客户端可能规定不准使用文件Cookie，所以现在的应用程序开发多使用内存Cookie。 ...负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。
当前端请求不携带cookie的时候，服务端设置： 'Access-Control-Allow-Origin': '*' 这时候不会报跨域的错误。...IP相同的情况下，开启了允许携带cookie，注入很简单。 因为是前后端分离，部署上去是没什么问题，开发的时候ip都是本机的，就出现死活注入不了cookie。配置了domain也都无法注入。...后来了解到，不同IP是无法由后台直接注入cookie，而且不同域名之间也是无法注入cookie的。好比百度无法给京东注入cookie。也都知道同一个域名下的子域名和这个域名cookie是共享的。...要注意的是，path最好设置一下/，前端setcookie也一样，否则默认注入的path是当前页面，另外的页面就获取不到cookie了。...罗里吧嗦了一堆，其实重点就两个，想要由服务端注入cookie，前台后台都需要开启允许携带cookie设置withCredentials，开启之后允许跨域的头要是完整地址，不同IP域名之间无法注入cookie
下次用户在这个浏览器（Browser）中，再次 访问服务时，请求中会带上这个Cookie，服务端根据这个Cookie就能找到对应的session，从session中取得用户的信息，从而 维持了用户的登录状态...近几年，随着前后端分离的流行，我们的项目结构也发生了变化，如下图： [image2] 我们访问一个网站时，先去请求静态服务，拿到页面后，再异步去后台请求数据，最后渲染成我们看到的带有数据的网站。...只要这3个相同，我们就可以在请求（Request）时带上Cookie， 在响应（Response）时设置Cookie。...所以，我们在做前后端分离时，前端和后端部署在同一域下，满足浏览器的同源策略，登录不需要做特殊的处理。 不同域下的前后端分离 不同域下，我们的响应（Response）能不能设置Cookie呢？...前端要设置允许发送和接受Cookie。
1.2 登录流程 登录的基本流程 ? 2 同域登录 目前大多数Web应用采用前后端分离方式进行开发。所以前端网站或应用都属于SPA（Single Page Application）。...如果前端，后台API部署在同域下，不存在跨域的情况，登录方式相对简单。 2.1 基于Session登录 服务器端使用Session技术，浏览器端使用Cookie技术。 ?...所以在用户登录前或退出后或者session对象失效时，肯定都是拿不到需要的登录凭证的。 2.2 基于Token登录 ?...前端获取到Token，存储到cookie或者localStorage中，在接下来的请求中，将token通过url参数或者HTTP Header头部传入到服务器 服务器获取token值，通过查找数据库判断当前...大多数需要登录的网站在用户验证成功之后都会设置一个 cookie，只要这个 cookie 存在并可以，用户就可以自由浏览这个网站的任意页面。再次说明，cookie 只包含数据，就其本身而言并不有害。
下次用户在这个浏览器（Browser）中，再次访问服务时，请求中会带上这个Cookie，服务端根据这个Cookie就能找到对应的session，从session中取得用户的信息，从而 维持了用户的登录状态...我们访问一个网站时，先去请求静态服务，拿到页面后，再异步去后台请求数据，最后渲染成我们看到的带有数据的网站。在这种结构下， 我们的登录状态怎么维持呢？...再看看后台打印的日志： name:test-----value:same 同域下，异步请求时，Cookie也能带到服务端。...所以，我们在做前后端分离时，前端和后端部署在同一域下，满足浏览器的同源策略，登录不需要做特殊的处理。 不同域下的前后端分离 不同域下，我们的响应（Response）能不能设置Cookie呢？...前端要设置允许发送和接受Cookie。
CSRF的防御 我们知道了CSRF攻击的原理，就可以做针对性的防御了。CSRF的防御可以从两个方面考虑，一个是后台接口层做防御；另一个则是在前端做防御，这种不同源的请求，不可以带cookie。...当用户点击转账按钮时，会给银行的后台发送请求，请求中包含_csrf参数，如下： POST /transfer HTTP/1.1 Host: www.a-bank.com Cookie: JSESSIONID...如果请求是从银行网站发出的，这个字段会是银行网站转账页的链接，比如：https://www.a-bank.com/transfer-view；如果是从恶意网站发出的，那么referer字段一定不会是银行网站...不过SameSite设置None，还要同时设置Cookie的Secure属性，否则是不生效的。...以上就是在前端通过Cookie的SameSite属性防御CSRF攻击，不过大家在使用SameSite属性时，要注意浏览器是否支持SameSite属性。
是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。...解决：前端提交请求时，转义为>；或者后台存储数据时进行特殊字符转义。 建议后台处理，因为攻击者可以绕过前端页面，直接模拟请求，提交恶意 2....这种方式是利用浏览器的cookie或服务器的session策略，盗取用户信息，模拟用户向第三方网站发送恶意请求。 CSRF比XSS更具危险性。...因为从WEB页面产生的所以请求，包括文件请求，都会带上cookie，这样，只要用户在网站A的会话还没有过期，访问恶意网站B时就可能被动发出请求到网站A，同时携带cookie信息，从而达到伪造用户进行恶性操作...如果攻击者有权限在本域发布评论（含链接、图片等，统称UGC），那么它可以直接在本域发起攻击，这种情况下同源策略无法达到防护的作用。
存储型XSS漏洞大多出现在留言板、评论区，用户提交了包含XSS代码的留言到数据库，当目标用户查询留言时，那些留言的内容会从服务器解析之后加载出来 3....3、设置黑名单与白名单 4、在开发时开发人员严格设置WEB安全编码规范 5、对cookie进行特殊防御 6、对进行网页编码实体化 7、对Session标记、验证码或者HTTP头的检查 具体如下： A.PHP...Policy的Http Header （作用：可以防止页面被XSS攻击时，嵌入第三方的脚本文件等） （缺陷：IE或低版本的浏览器可能不支持） 2.在设置Cookie时，加上HttpOnly参数 （作用...：可以防止页面被XSS攻击时，Cookie信息被盗取，可兼容至IE6） （缺陷：网站本身的JS代码也无法操作Cookie，而且作用有限，只能保证Cookie的安全） 3.在开发API时，检验请求的Referer...就意味着后台的管理人员会被x到 那么这种场景的xss就叫xss的盲打 2.
网站的划分一般为二：前端和后台。我们可以理解成后台是用来实现网站的功能的，比如：实现用户注册，用户能够为文章发表评论等等。而前端呢？其实应该是属于功能的表现。...除了后台需要在性能上做优化外，其实前端的页面更需要在性能优化上下功夫，只有这样才能给我们的用户带来更好的用户体验。...同理，网站也是这样，网站前端的用户体验决定了用户是否想要去使用网站的功能，而网站的功能决定了用户是否会一票否决前端体验。...另一方面，对于某些静态资源的访问，如CSS、script等，发送cookie没有意义，可以考虑静态资源使用独立域名访问，避免请求静态资源时发送cookie，减少cookie传输次数。...由于CDN部署在网络运营商的机房，这些运营商又是终端用户的网络服务提供商，因此用户请求路由的第一跳就到达了CDN服务器，当CDN中存在浏览器请求的资源时，从CDN直接返回给浏览器，最短路径返回响应，加快用户访问速度
，分别安装前端和后端，从Azure后台创建服务器开始，全面详解面板的安装。...前端部署 web环境的部署 前端界面主要用于管理服务器和与用户交互使用，需要使用到Web服务器，这里我们使用宝塔快速部署环境。...面板程序的安装 使用SSH，进入网站根目录，开始安装前端。...至此，前端部分安装完成，下一步我们将安装后端 后端部署 前端部署完成后，我们将在这台服务器上继续安装，部署后端，以实现对接。...点击create，接着点击生成token，一键部署配置 把获得的命令复制到服务器中执行，程序将自动配置 部署完成后，编辑配置，修改证书地址 Bash [root@pterodactyl daemon
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
