这将非常有用,对吧?现在,当您想在服务器端做出关于向客户端提供什么的决策时,使用用户代理(User Agent)“嗅探”非常普遍。但是,UA嗅探一直很糟糕,而且每天都在变得更糟。您真正想知道的是诸如“我正在向其提供服务的屏幕有多大?”或“我正在向其提供服务的设备是否具有触摸事件?”之类的信息 - 这样您就可以提供适合这些问题的资源。有没有办法在服务器端获取准确的客户端信息?
为什么在服务器端?
如果您确定正在向小型移动设备、电视或其他设备提供服务,则可能希望提供完全不同的布局或布局的不同部分。请参阅本文。
将数据存储在 Cookie 中
我认为使客户端信息在服务器端可用最简单的方法是将这些数据存储在 Cookie 中。Cookie 会在发送到该域的所有请求的标头中发送,因此服务器可以访问它们。如果该 Cookie 中包含有关浏览器窗口大小的信息,则服务器可以使用它。
Cookie 逻辑
为了做出您想要的明智选择,您需要此 Cookie 存在。如果它存在,那就太好了。如果它不存在,请执行设置 Cookie 所需的最低限度客户端测试,然后刷新。
以 PHP 为例
<?php if isset(($_COOKIE['_clientInfo'])) { ?>
<p>You have the cookie, so put in your logical stuff here and load the document as you will.</p>
<?php } else { ?>
<p>You don't have the cookie yet, so don't load anything but the resources you need to test the client and set the cookie. Then refresh.</p>
<?php } ?>
设置 Cookie
您可能需要什么信息?屏幕尺寸很可能。可能任何 Modernizr 可以告诉您的信息。
在 JavaScript 中设置 Cookie 很容易。
document.cookie = "cookieName=" + value;
使值易于解析并执行您需要的操作。这里让我们将其设置为 JSON 字符串。我们将创建一个包含所有所需数据的对象,并使用一些 jQuery 和 Modernizr 获取我们想知道的值。
var clientInfo = {
browserWidth: $(window).width(),
browserHeight: $(window).height(),
flexboxSupport: Modernizr.flexbox,
SVGSupport: Modernizr.svg
};
document.cookie = "_clientInfo=" + JSON.stringify(clientInfo);
在测试中,我遇到了一些 Opera 问题,因此切换到 jQuery Cookie 插件,并且它运行良好。
var cookieVal = JSON.stringify(clientInfo);
$.cookie("_clientInfo", cookieVal, {
expires: 7
});
设置 Cookie 后刷新
现在 Cookie 已设置,您可以刷新页面,以便文档可以实际加载所有这些有价值的信息。
window.location.reload();
注意:刷新有点棘手,请阅读此内容。
卡顿警告?
如果您不喜欢刷新的想法,您可以编写它,以便在设置 Cookie 的同时加载某种默认文档。这样不会造成任何损害。
Cookie 应该持续多久?
我不知道。可能一个小时?永远?您有可能在用户的桌面浏览器处于异常状态时捕获到他们。例如,他们将其缩得很小,然后加载您的页面,然后他们将永远获得小屏幕版本。或者,该浏览器的更新版本提供了更多高级功能,但您的旧 Cookie 仍然存在。由您决定。
这是一个一小时的示例
var now = new Date();
var time = now.getTime();
time += 3600 * 1000; // one hour
now.setTime(time);
document.cookie = "_clientInfo=" + JSON.stringify(clientInfo) + ";expires=" + now.toGMTString();
在服务器端使用信息
仅以 PHP 为例,您可以轻松地获取 Cookie 并访问我们作为 JSON 保存的数据位。
<?php
$json = $_COOKIE['_clientInfo'];
$obj = json_decode(stripslashes($json));
echo "<p>Browser Width: " . $obj->{'browserWidth'} . "</p>";
?>
您不会像上面那样简单地将其输出,而是会对这些数据使用一些逻辑,并执行您将要执行的任何花哨的特殊资源和内容提供。
在客户端使用信息
此目的在于服务器端访问,但是,您也可以在客户端访问该 Cookie。这意味着,理论上,您不需要再次加载 Modernizr,因为您已经拥有了这些信息。
这是一个简单的示例,它获取数据并显示其中的一部分
var clientInfo = JSON.parse("<?php echo $_COOKIE['_clientInfo']; ?>");
var output = "<p>Browser Width: " + clientInfo.browserWidth + "</p>";
$("#clientInfo").append(output);
演示
最简单的演示 仅用于说明它是可行的。
缺点?
我不知道。我怀疑有很多缺点,否则我认为这种事情会更频繁地发生。聪明的人:在评论中发表意见,让我知道利弊。
我怀疑这可能会使缓存变得复杂。也许读取/发送 Cookie 的次数过多是一个问题?对于那些不允许使用此类 Cookie 的人来说又该怎么办?必须确保他们不会陷入任何无限循环或导致站点无法使用。
其他事项
- 我第一次听说使用这种方法是在 Matt Wilcox 的 自适应图像 中,其中屏幕分辨率被保存为 Cookie 并用于做出关于使用哪种图像类型的选择。
- 客户端提示 也是一项旨在提供这些信息而无需进行所有这些花哨操作的技术。
- James Pearce 的 modernizr-server
modernizr-server 库是一种将 Modernizr 浏览器数据引入服务器脚本环境的方法。
- Dave Molsen 的 Detector
Detector 是一个简单且基于 PHP 和 JavaScript 的浏览器和功能检测库,它可以自行适应新设备和浏览器,而无需从浏览器信息的中央数据库中提取信息。
- Shane Gliser 在他的书 使用 jQuery Mobile 创建移动应用程序 中谈到了这一点,但将其保存到 HTML5 本地存储中。
我的建议:确保加载程序(或您采用的任何引导过程)执行所有必要的嗅探以了解其运行位置。无论如何,浏览器都拥有大量此类信息。
然后,加载器会获取任何与分辨率、功能等不同的资源。
您在此处描述的大部分内容都是 Modernizr 的用途。通过使用可用的功能为
<html>元素添加类,您也可以在 CSS 中按情况加载资源。我唯一希望的是我们不必自己编写这些代码。在我的待办事项列表中,要在croquetscores.com上实现此功能,因此我目前还无法评论该技术的优缺点。
我目前使用的一种技术是通过查询字符串包含信息。另一个想法是通过 JSON 调用发布信息到 API 类型服务。
嗯……有趣!
您的评论不是
(这个也不是)。
对我来说很有道理。这似乎是那些应该成为标准并且可能有一天会成为标准的事情之一。UA 字符串在浏览器相互伪造方面变得越来越复杂,它们应该准确地识别自己并添加诸如此类有用的信息。
$obj = json_decode(stripslashes($json));
您**永远不应该**使用
stripslashes(),除非您绝对需要。(如果您确实“绝对需要”,那么您遇到了应该解决的问题。)stripslashes()用于抵消 PHP 过去的一个糟糕想法的影响:magic_quotes_gpc。Magic Quotes 是一次试图在编码人员不了解安全性的情况下提高安全性的错误尝试。不幸的是,它们是许多编程烦恼/错误(最佳情况)甚至新的安全风险(最坏情况)的根源。Magic Quotes 已被**弃用**,并在 PHP 5.4 版中删除。如果您使用的是早期版本的 PHP,则应停止当前操作,并确保 Magic Quotes 已**关闭**(请参阅我上面的链接获取说明;在此处了解更多信息)。
如果您遇到不知道是否会打开 magic quotes 的情况,则应在使用
stripslashes()之前进行检查。(……此外,在不需要时对 JSON 使用
stripslashes()实际上可能会破坏 JSON 字符串。)需要注意的一件事:“仅限 HTTP”的 Cookie。
OWASP 的一部分,这是 OWASP Wiki 链接:https://www.owasp.org/index.php/HttpOnly
文章摘录:“在生成 Cookie 时使用 HttpOnly 标志有助于降低客户端脚本访问受保护 Cookie 的风险(如果浏览器支持)。“
我的整个公司都正在转向此功能。
虽然方便且无害,但我不知道这有多必要。
HTTPOnly的目标是防止诸如会话密钥之类的私人信息泄漏到其他站点。如果一个恶意站点注入 JS 来访问 Cookie,它可以完全跳过 Cookie,自己收集相同的信息,然后转发。tl;dr 扩展和缓存变得很棘手。
我以前做过这样的事情。以下是我学到的东西……
在 PewResearch.org 网站上,我们创建了一个移动版本。“移动”由服务器通过用户代理嗅探确定。一旦我们知道您是否被视为移动用户,我们就会设置一个类似于 device=mobile 或 device=desktop 的 Cookie。仅当未发送该设备 Cookie 时,才会进行用户代理嗅探。
我们使用 WordPress,因此我有一些条件函数来确定请求是桌面用户还是移动用户,即 is_mobile() 和 is_desktop()。移动用户将获得不同的样式表、简化的 header.php 和最小的 footer.php。我们网站的其余逻辑基本上相同。这样做的全部目的是修改移动版本的一些内容,而不是完全重写桌面版本中的所有内容。它运行得相当不错……但并不完美。
那么哪里可能出错呢?
**规模**。当相同的 URL 生成不同的标记时,您将遇到缓存问题(CDN、WP Super Cache 等)。您不希望桌面用户看到移动视图。
我们使用两层缓存:CDN 缓存整个 HTML 和静态资源,以及 WP Super Cache,它通过创建结果的静态 HTML 副本并提供该副本来减少创建特定页面所需的次数。
为了解决 CDN 问题,我编写了一个 RegEx,以便在 CDN 级别上的每个请求中检查 Cookie(我们使用 EdgeCast,并且它们具有执行此操作的功能)。如果设备 Cookie 设置为移动,那么我们将该请求传递回源服务器,从而有效地绕过 CDN。桌面 Cookie 用户将获得正确版本的页面。基本上,移动用户对 HTML 内容的请求将由源服务器处理,桌面用户将获得 CDN 的好处。
我不得不稍微修改 Wp Super Cache 插件(大约 2 行),以使其根据 Cookie 值提供请求的不同版本。WP SUper cache 将静态 HTML 文件存储在 /wp-content/cache/site-name.org/2013/04/28/slug-name/index.html 中,我只是将路径更改为 /wp-content/cache/site-name.org/2013/04/28/slug-name-mobile/index.html 或 /wp-content/cache/site-name.org/2013/04/28/slug-name-desktop/index.html
最终,我们收到了越来越多的移动请求,CDN 未用于这些请求,因此我们的服务器不堪重负,速度变慢等。响应式设计比我正在做的事情要好得多,但在开始时,让这个服务器端 Cookie 切换工作是有意义的。我们使用了大约 1.5 年。当时它很有意义。
我可能解释得不够好,因为我刚从 ConvergeSE 开了 8 个小时的车回来,我累了。
我必须同意 Russell 的观点。用于动态内容的 CDN(例如,您将所有内容推送到边缘)可能是此技术的最大障碍。Guy Podjarny 指出,Akamai 的一些技术将帮助您解决此问题,但我并不完全确定。如果您能够解决这个特定问题,那么您的其他问题就是
也就是说,我确实喜欢这种技术,我们正在与西弗吉尼亚大学主页一起使用它,并且我还有一个概念验证演示。圣母大学(切换您的 UA)也做了类似的事情。已经有一些服务器端 Modernizr 实现。结合响应式设计,它实际上提供了相当大的灵活性,并且,如果您像我一样,您可以更多地在服务器上进行条件加载,而不是依赖 JavaScript。我喜欢第一次就获得正确标记的想法。
我觉得使用这种方法,您需要不要盲目依赖 Cookie 中的信息,并不断重新检查其准确性。
对桌面浏览器上可能很容易更改的宽度和高度等内容做出假设。
如果错误地使用了这种技术,可能会比用户代理“嗅探”更糟糕。如果您的用户使用较小的窗口访问,并且您的 Cookie 具有较长的过期时间,迫使他们像
[此示例](http://m.bigpond.com/“Bigpond 的固定 320px 移动网站 :'(“)
诸如 flexbox 之类的东西是很好的信息,但是如果您要提供两个模板,则必须维护这两个版本,这听起来比它的价值更麻烦。
看看此类内容的真实示例,以了解性能方面的盈亏平衡点从哪里开始,将会很有趣。
这有点像 BEM。
并且某些防病毒软件在快速页面重新加载/重定向方面存在问题。
已经存在,仅用于服务器端
https://github.com/jamesgpearce/modernizr-server
或者由我本人分叉以在客户端保留这些值
https://github.com/aarontgrogg/modernizr-server
仍然是一个相当大的性能延迟,需要额外的、尽管最小的往返行程,以及几个相当大的浏览器 Cookie。
另请注意,如果设备不支持 Cookie,这将变成一个无限循环……
但除了这两个缺点外,优点还是相当突出的!
干杯,
Atg
需要考虑的一件事是,Cookie 将与发送到 Cookie 设置到的相同域的任何 HTTP 请求一起发送,包括图像、样式表、JS 文件等的请求。因此,除非您从无 Cookie 域提供静态内容,否则会有一些请求开销。https://developers.google.com/speed/docs/best-practices/request
如果你的唯一目的是根据客户端的显示指标和支持的功能来显示不同的数据表示形式,我认为这样做没有意义。
这就是 RWD 的用途,只需使用 CSS 媒体查询来更改页面外观和可用内容。
@Octavian
其他一些好处可能是基于设备功能自定义页面组件(例如,
if (!Modernizr.geolocation) { // 包含输入以询问位置 })或根据屏幕尺寸以编程方式确定正确的图像 SRC,这样你仍然可以利用浏览器预取功能,并且不必依赖(和等待)基于 JS 的响应式图像……我个人尽量避免依赖会话,因为 Russell 提到的可扩展性和缓存问题。
如果你想根据客户端信息做出决策,我认为ajax include / 条件加载可能更可靠且更易于测试,因为它们不依赖于先前状态。
一些相关链接
Alex Sexton 的 JS 应用部署指南,其中讨论了条件加载所有内容以及根据客户端功能集缓存站点的不同版本
Alex Russell 的建议是使用客户端功能检测来构建 UA 及其功能集的服务器端索引,以便你可以执行更可靠的 UA 探测
缺点
1) 请求开销
2) 你需要验证数据 - 虽然你可以随意伪造几乎所有东西,但编辑 cookie 相对容易得多。显然,使用此功能不会造成太大危害,但它是你需要清理的另一个输入。
替代方案?
如果你已经在使用 PHP 会话,请不要创建另一个 cookie,只需添加另一个会话变量 - 这是我见过的最流行的解决方案。这也有类似的缺点,但可能会减少开销。
另一种替代方案?
执行一次客户端重定向,在检测到正确的参数后,重定向到mobile.domain.com或tablet.domain.com。这假设你只有少量需要呈现的不同网站(这应该是这种情况),并且你的响应式设计负责其余工作。这消除了开销问题,因为只有请求 URL 的大小增加了几个字符。
不错的文章..
如何使用
window.screen.width等代替当前浏览器窗口宽度?因为他们可能一直都在使用小尺寸窗口。例如,我在 FHD 屏幕上查看网页,但只使用一半的宽度作为浏览器本身。
@Yotamb:jQuery 的
$(window).width()不会给你浏览器视口的宽度吗?一些事情(即使这只是示例代码)
你提供的 PHP 示例将一些未转义的 cookie 内容转储到页面中。这里有 XSS 漏洞。(例如,如果
browserWidth设置为<script>alert('rawr!');</script>?)是的,你只能轻松地对自己造成这种影响,但中间人可以轻松地篡改 cookie。至少值得提及这种风险,因为 cookie 通常应被视为不受信任的内容。在客户端代码中,与上面相同的转义问题,但还有:为什么要使用 PHP 将 cookie 内容转储到客户端变量中?你可以在客户端读取 cookie,不是吗?
始终确保你的网站在 JS 和/或 cookie 不可用的情况下能够优雅地回退。否则,浏览器可能会陷入[*]无限重定向循环中,搜索不会设置的 cookie。
此外,即使你使用
window.screen.width来存储值而不是浏览器更易更改的尺寸,我们这些笔记本电脑用户也可能会根据我们是否与外部显示器对接来更改屏幕尺寸。我们有些人每天都会多次对接和分离,因此缓存失效变得非常重要。-Tim
[*]
虽然浏览器通常会捕获这种情况,但当你只需要一些额外的浏览器数据时,这是一种糟糕的用户体验。
使用 WebSockets 或类似于 Node 和 socket.io 的东西,这种操作会更容易一些。你可以只加载一个包含 WebSockets 接口的最小脚本,然后将有关客户端的信息作为与事件关联的数据发送到服务器,然后让服务器发送相应的数据。这基本上与刷新技术相同,但稍微流畅一些。
这听起来确实是一种很有趣的技术。Jacopo,如果你有时间,我很乐意看到一篇关于此的文章/演示。
当你只需在查询字符串中使用一些适当的标志进行 GET 请求时,这听起来完全没有必要。
其他一些相关的资料可能也值得关注
Yiibu 进行了一个非常类似的实验,他们使用 PHP 开发,称为Profiler。它在客户端构建配置文件,然后将其存储以供后续请求使用,并建立一个用于类似设备的隐性知识数据库。他们甚至有一套非常棒的幻灯片来解释这个过程。
Dave Molsen 扩展了这个想法,制作了Detector,它使用Modernizr来解析浏览器和设备功能,然后将设备分类为不同的类别。
另一个受 Yiibu Profiler 启发的现实世界中的例子,由 Orde Saunders 提供。
我正在我目前正在进行的一个项目中使用这种技术,它运行良好。我所做的只是在 cookie 中设置浏览器宽度,并通过这种方式使其可用于服务器。不过,需要注意一些事项
我不刷新页面。如果未设置 cookie(例如在第一次加载时),我会回退到有意义的默认值
我不将此技术用于任何重要的布局更改。为此,我们有媒体查询
我将此用作锦上添花的次要优化
例如:在我的项目中,某些页面会加载地理地图。在移动设备上,它们的可用性很糟糕。因此,在移动设备上,我不根据此 cookie 加载该标记,而是显示包含位置的文本字符串。在较大的客户端上,会加载地图。如果未设置 cookie,则会加载地图。
我认为你可以安全地使用此技术进行此类非关键优化,但我建议在根据此做出任何重大设计决策时要非常谨慎。
如果不用刷新,而是使用 ajax 获取适当的数据呢?(刷新作为回退)
我知道,UA 探测并不总是执行此操作的最佳方法,但另一种可能性是WURFL。
它将用户代理字符串映射到它们表示的设备和/或浏览器,并拥有设备/浏览器支持的大量功能列表。API 非常易于使用,并且可以提供你所需的所有信息,而无需设置 cookie 或刷新页面。
哦,它还知道各种移动设备的屏幕尺寸。
我遇到的最完整的服务器端探测解决方案之一是 Dave Olsen 的 Detector。它用于西弗吉尼亚大学的网站。
这是一个演示
http://detector.dmolsen.com/
以及 GitHub 仓库
https://github.com/dmolsen/Detector
另一种可能性是探测客户端数据,然后使用 ajax 加载页面其余部分。
至少对于 Google 来说,搜索引擎问题可以得到解决
https://developers.google.com/webmasters/ajax-crawling/
有时我会将服务器端数据提供给客户端。这与你在这里提到的完全相反,原因完全不同,但是的,这非常有用……谢谢!
我最近不得不执行类似的 hack;我正在将结账集成到支付提供商的移动结账中。唯一的缺点?他们希望提前知道何时应该提供移动版本。
我最终将信息存储在会话中以节省 HTTP 开销,并确保在用户实际完成时将其清除。
我有一个小问题,因为我不确定,这是否会以任何方式影响 SEO?需要重定向会导致 Google 在刷新后或刷新前索引?我猜应该是后者,但无论如何我还是想问问。
如果用户禁用了 Cookie,如何避免无限刷新循环?
在使用您收集的数据刷新页面之前,您可以查看是否可以从 Cookie 中读取数据。如果不能,则重定向到一个包含请求变量的页面,该变量实质上告诉您的服务器端程序用户不支持 Cookie。然后,您的服务器端程序很可能只提供所有默认的资产/内容。您可以执行类似的操作来捕获禁用 JavaScript 的用户和机器人。
对我来说,最大的缺点是重新加载对分析和简单的浏览器历史行为(后退按钮问题)的影响。您需要根据 Cookie 数据的存在或更改构建一个分析抑制器,并且理想情况下从浏览器历史记录中删除原始页面,以便保持某种正常行为。
这是一个足够好的想法,但在企业环境中肯定会需要更结构化的实现。
不要这样做,船长。
您的域名设置的每个 Cookie 都会与对该域名的每个浏览器请求一起传输。所有 Cookie 都会添加到每个资产下载甚至 XMLHTTP 调用的请求标头中。
如果您关心 SEO,请尝试使用 G**gle PageSpeed 并查看相应的警告。它会清楚地告诉您要使用无 Cookie 方式或至少减少 Cookie 数据量。
最佳折衷方案是
使用包含会话 ID 的一个 Cookie(您的服务器框架可能会提供开箱即用的基于 Cookie 的会话处理)。让您的 JS 框架对所有用户数据进行采样,并使用 XMLHTTP、JavaScript 注入(又名 JSONP,但在这种情况下可能没有“P”)或简单的图像源将其传输到您的服务器。接收服务器脚本将数据与会话 ID 一起存储在服务器数据库中。现在,从您的浏览器进行任何后续调用时,被调用的脚本可以提取会话 Cookie,从数据库中检索用户数据并相应地做出反应。
如果您真的关心速度,可以使用 memcached 来临时缓存用户数据。
JavaScript 注入和图像源允许将用户数据发送到与您的页面 URL 不同的域。
您可能希望以两种方式存储会话 ID
只要服务器没有用户数据,ID 就只是 ID。收到数据后,在 ID 中添加一个标记,该标记可以在分析期间轻松删除(例如,“4709237407”变为“4709237407_ok”)。您的 JavaScript 框架分析 Cookie 值,如果它采用扩展语法则中止。使用此策略,您可以最大限度地减少 XMLHTTP/JSONP 调用和数据库/缓存访问。当然,这种方法意味着您必须编写自己的会话处理;例如,PHP 会话不允许修改现有的会话 ID。
James Pearce 创建了一个名为 modernizr-server 的项目,该项目运行 modernizr 测试并将结果序列化到 Cookie 中,然后刷新页面。在他的自述文件中,他谈到了注意事项。需要注意的是在包含表单的页面上使用它……
“建议您首先在用户使用 GET 方法访问的页面上使用 modernizr-server.php。如果第一个请求是 POST(例如来自表单),则页面的刷新将导致浏览器询问用户是否要立即重新提交表单,这可能会让他们感到困惑。” – Pearce
另一个类似的项目是 Matt Stauffer 的 Simple RESS。这是一个不错的项目,如果您对这些技术感兴趣,值得一试。
我个人不使用这些,更喜欢使用 Filament Group 在其 SouthStreet 工作流程中使用的更多工具,例如 AJAX Include Pattern 和 AppendAround(如果需要更改标记顺序)。
如果您确实使用了这种使用客户端设备/浏览器数据创建 Cookie 的技术,我认为在您的 PHP 中使用 Vary HTTP 标头 会很有用。
Cookie 可能会被浏览器禁用,并且需要刷新对于移动优化来说是不利的。
演示中的数字看起来很奇怪。并且服务器/客户端显示相同的内容
“建议您首先在用户使用 GET 方法访问的页面上使用 modernizr-server.php。如果第一个请求是 POST(例如来自表单),则页面的刷新将导致浏览器询问用户是否要立即重新提交表单,这可能会让他们感到困惑。”
+1 同意
我不确定这是否是正确的方法。
它不可靠(用户可以禁用 Cookie),对 UX 不利(刷新)并且性能不佳(Cookie 大小的开销),搜索引擎可能也不太喜欢这种解决方案(不确定,但似乎有可能)。
遗憾的是,我现在想不出更好的解决方案。
我们在旧版本的 Drupal 版 Modernizr 中使用了功能检测的服务器端存储,但事实证明这非常麻烦。首先,重新加载的卡顿很糟糕。其次,当人们旋转手机之类的事情时会发生什么?
在简要支持提供此功能的库后,我可以肯定地说它带来的麻烦往往多于其价值。但是,如果您想执行 RESS 或类似操作,我认为最好尝试在服务器端使用功能检测结果而不是 UA 检测。
很疯狂,但您可以将内部锚点点击绑定到提交带有数据的 post 表单以供下一页使用(在登录页面上提交表单)。
我做了一个粗略的 演示,我相信有一些缺点。
我更喜欢使用带有 HTTP Only 和持续再生 ID 的 PHP 会话。首先,您不必担心 Cookie 大小,因为它占用空间很小,并且所有数据都存储在您的服务器上。其次,数据确实存储在服务器端,这使得访问它更容易。第三,不需要可能存在跨浏览器问题的 JavaScript Cookie 库。第四,您可以保护用户免受可能从这些信息中获益的恶意行为者的侵害。
要做到这一点,请学习有关会话的知识。 https://php.ac.cn/manual/en/ref.session.php 然后创建一个您可以向其发送 ajax post 的 php 文件。然后创建一个可以从中检索它的文件。最聪明的方法是在此基础上使用会话令牌系统来验证 post 和检索请求。
关于如果他们禁用了 Cookie 的问题,只需在第一段存储数据上执行 isset($_SESSION[‘whatever’]) 即可。如果是,则执行您需要执行的操作。如果不是,则使用备用方案。您的用于检索的 php 文件应具有此类方法,并且您的 ajax 响应应在无法获取存储结果时从 php 文件获取响应,并执行您的备用方案。
嗨,Chris,您的演示中存在问题!
它不会停止刷新!
您可能已阻止 Cookie。如果您实际实施此操作,则需要处理这种情况。