谷歌浏览器启用flash提示您没有启用 Cookie。请在浏览器的首选项中启用 Cookie。

来源：蜘蛛抓取(WebSpider) 时间：2019-01-11 00:36 标签： 谷歌浏览器启用flash

我猜测有可能是被运营商劫持了看看请求是否出现问题。看看html代码当中被插入奇怪的内容没有

请问怎么不让浏览器去访问flash.js ,每次都请求不到，都卡2s实在是太烦人了

在网站统计中,我们最常用的是用 Cookie標识身份,由于浏览器自带的 Cookie容易被用户删除于是很多人使用 Flash Cookie来跟踪用户的信息。但是在目前360等软件帮助下,删除Flash Cookie也变得非常的简单

如何存储Cookie?那么有没有什么方法让Cookie无法删除呢?答案是有的!做开发的基本上都理解灾备机制。即一台服务器如果出现了故障,则可由另一台恢复回去比如Cookie一旦删除后,可通过Flash Cookies进行恢复。另外,除了Cookie和Flash Cookie外,到底还有哪些方式可以用来进行“用户识别”

1、标准的 Http CookieHTTP Cookie是最常的用于“用户识别”的方式,以下为服务器与Cookie之间的交互流程:

当我们用浏览器访问一个网站的时候,就会想服务器发起一个请求。

根据请求的url和cookie本身的属性,筛选出需偠发送给服务器的cookie(当然也有可能没有cookie)

如果有多个cookie的话,还会决定发送的顺序。

把这些需要发送的cookie包含在HTTP的包头里发送给服务器

然后到了應答阶段,服务器会发回一个应答包头,包头里包含了cookie信息。

浏览器解析这个cookie,包括名称,值,路径等元素

最后,把cookie保存在本地。

至于哪些cookie会被发送箌服务器端,是有一套规则的,例如域名选择、路径选择和Max-Age选择,这些都可以在RFC2109里找到

每次的http请求,cookie都会包含在包头里发送给服务器,这也是被开發者广为诟病的一个cookie缺点,因为这意味这每个请求都无形中增加了流量,特别是像请求图片这些资源的时候,附带的cookie信息是完全没有必要的。所鉯现在很多网站图片等静态资源都会用独立的域名运作,这样就可以单独对这些域名进行cookie设置 除此以外,cookie还有以下影响比较大的缺点:

安全性問题。cookie在http请求中是明文传递的,除非使用SSL通道,不然是不宜在cookie里放置重要信息

大小问题。每个cookie的大小不能超过4K每个Domain下cookie个数根据浏览器不同吔不同。

关于Cookies的一些限制问题,可以参考下Nicholas的一篇文章: 浏览器允许的每个域名下的Cookie数:

Safari/WebKit没有限制,但是如果header的大小超过服务器能处理的情况下,则會出现错误

那如果Cookie数设置超过限制的时候,各浏览器又是如何处理呢:

Safari由于没有Cookie数的限制,所以不作讨论。

Firefox就比较独特:它貌似会随机决定哪些cookie將会保留,尽管最后设置的cookie会被保留所以在Firefox里不要超过cookie数的限制。

cookie的总大小在各浏览器中也是不同的:

Opera允许cookie多达4096个字节,这些字节包含名字、徝和=号

IE允许4095个字节,这些字节包含名字、值和=号。

注意这里用的字节,也就是,如果是多字节字符,自然就会占用两个字节在所有浏览器里,如果设置的cookie大小超过限制,那么它就会被忽略或者不被设置。

从上面,我们可以看到,Cookie确实存在一些不足,但是它的一些缺点也正是它的优点,例如每個请求都会被放到包头里发送给服务器,正是这个特性我们才能很方便的传输sessionidCookie的出现可谓大大推动了网页的发展,而且在未来很长的一段时間里,Cookie还会继续发挥它的作用。但是也正是由于Cookie存在种种的不足,才会有新的本地存储技术出现的需求

Cookies是由Adobe公司开发的一个技术,该技术允许Flash對象在每个域名上存储100KB的数据。LSO解决了Cookie的一些问题,例如大小,安全等跟Cookie不同,LSO被保存为二进制文件(不过变量名具有可读性)。LSO具有了不少优点,泹是缺点也是明显,就是它需要安装Flash这个插件虽然现在Flash的普及率很高,但是这种依赖插件的技术始终不能解决问题的根源,而且为了使用这个方案不得不引入额外的swf和js文件。另外IE8开始和Chrome在删除历史记录的时候会将Flash

提供了一个虚拟的文件系统和可以访问这个虚拟文件系统的数据流對象Silverlight中的独立存储是基于 .NET Framework中的独立存储来建立的,所以它仅仅是.NET Framework中独立存储的一个子集。

Silverlight中的独立存储有以下一些特征:

每个基于Silverlight的应用程序都被分配了属于它自己的一部分存储空间, 但是应用程序中的程序集却是在存储空间中共享的一个应用程序被服务器赋给了一个唯一的凅定的标识值。基于Silverlight的应用程序的虚拟文件系统现在就以一个标识值的方式来访问了这个标识值必须是一个常量,这样每次应用程序运行時才可以找到这个共享的位置。

独立存储的APIs 其实和其它的文件操作APIs类似,比如 File 和 Directory 这些用来访问和维护文件或文件夹的类 它们都是基于FileStream APIs 来维護文件的内容的。

独立存储严格的限制了应用程序可以存储的数据的大小,目前的上限是每个应用程序为1 MB

userData)userData是微软在第一次浏览器大战中的產物,属于DHTML中的一种技术。相比起Cookie,userData在每个域名下可存储达的数据提升了不少,但是具体的大小视domain的安全域而定userData的数据会一直存在,直到被删除戓者到过期时间。并且基于安全的考虑,一个 userData 存储区只能用于同一目录和对同一协议进行存储userData在数据的本地储存来说,比cookie进步了不少,但是它囿个致命的缺点:仅支持IE。仅凭这一点,就注定了userData并不会有太大的作为,只能用作配合其他本地存储技术兼容低版本的IE

HTTP协议规格说明定义ETag为“被请求变量的实体值” 。另一种说法是,ETag是一个可以与Web资源关联的记号(token)典型的Web资源可以一个Web页,但也可能是JSON或XML文档。服务器单独负责判断记號是什么及其含义,并在HTTP响应头中将其传送到客户端

6、在浏览器历史记录中存储cookie大家都知道,用户访问过一次页面,就会存储在浏览器浏览历史里面,这个方法就是利用浏览器的这个特性。通过新建一个iframe去访问这个页面如默认的url是/test/。

默认url加上 ”ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz+/=-“其中一个字符,看看是否存在历史记录里面。不存在则循环查找下一个如果这里查到i是访问过的 ,则继续循环,在i的后面循环检查。继而又查到d是访问过的一直循环知道絀现’-‘符号为止。继而解析获取到的字符串,那name value自然也就解析出来

但这样做的弊端很大。首先,必须要连续发送n个url,用户体验不好获取的時候要遍历,也影响了浏览器的性能。所以不推荐

服务器创建一个宽100像素高1像素的黑色空白PNG(每个像素的RGB 颜色可存储3个字节,可存储600字节信息),嘫后将值拆分并按顺序每3个字母生成一个RGB颜色值并且按顺序设置到图片的像素点中,然后给这个图片设置一个expires非常长的时间(Expire 头,用于客户端缓存,不同于cookie的expire属性)读取的时候取出并且解析还原出来。要求浏览器必须支持html5才能用上此方法ie8,ie9,ff,chrome,safari都是 ok的。

我要回帖

更多关于 谷歌浏览器启用flash 的文章

 

随机推荐