整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

HTML 中引入 CSS 的方式

4 种方式可以在 HTML 中引入 CSS。其中有 2 种方式是在 HTML 文件中直接添加 CSS 代码,另外两种是引入 外部 CSS 文件。下面我们就来看看这些方式和它们的优缺点。

内联方式

内联方式指的是直接在 HTML 标签中的 style 属性中添加 CSS。

示例:

<div style="background: red"></div>

这通常是个很糟糕的书写方式,它只能改变当前标签的样式,如果想要多个 <div> 拥有相同的样式,你不得不重复地为每个 <div> 添加相同的样式,如果想要修改一种样式,又不得不修改所有的 style 中的代码。很显然,内联方式引入 CSS 代码会导致 HTML 代码变得冗长,且使得网页难以维护。

嵌入方式

嵌入方式指的是在 HTML 头部中的 <style> 标签下书写 CSS 代码。

示例:

<head>
 <style>
 .content {
 background: red;
 }
 </style>
</head>

嵌入方式的 CSS 只对当前的网页有效。因为 CSS 代码是在 HTML 文件中,所以会使得代码比较集中,当我们写模板网页时这通常比较有利。因为查看模板代码的人可以一目了然地查看 HTML 结构和 CSS 样式。因为嵌入的 CSS 只对当前页面有效,所以当多个页面需要引入相同的 CSS 代码时,这样写会导致代码冗余,也不利于维护。

链接方式

链接方式指的是使用 HTML 头部的 <head> 标签引入外部的 CSS 文件。

示例:

<head>
 <link rel="stylesheet" type="text/css" href="style.css">
</head>

这是最常见的也是最推荐的引入 CSS 的方式。使用这种方式,所有的 CSS 代码只存在于单独的 CSS 文件中,所以具有良好的可维护性。并且所有的 CSS 代码只存在于 CSS 文件中,CSS 文件会在第一次加载时引入,以后切换页面时只需加载 HTML 文件即可。

导入方式

导入方式指的是使用 CSS 规则引入外部 CSS 文件。

示例:

<style>
 @import url(style.css);
</style>

比较链接方式和导入方式

链接方式(下面用 link 代替)和导入方式(下面用 @import 代替)都是引入外部的 CSS 文件的方式,下面我们来比较这两种方式,并且说明为什么不推荐使用 @import

  • link 属于 HTML,通过 <link> 标签中的 href 属性来引入外部文件,而 @import 属于 CSS,所以导入语句应写在 CSS 中,要注意的是导入语句应写在样式表的开头,否则无法正确导入外部文件;
  • @import 是 CSS2.1 才出现的概念,所以如果浏览器版本较低,无法正确导入外部样式文件;
  • 当 HTML 文件被加载时,link 引用的文件会同时被加载,而 @import 引用的文件则会等页面全部下载完毕再被加载;

小结:我们应尽量使用 <link> 标签导入外部 CSS 文件,避免或者少用使用其他三种方式。

前言

  在跨域请求不同服务方或是兼容先前系统的页面时,你可能想利用AJAX从网页上下载HTML并粘贴到div中,这将带来不安全注入的问题。

  此时,通过iframe页面嵌入可以很好地解决上述问题。

本文带您了解iframe内联框架,帮助您提高页面集成效率和复用率,一次开发,多次使用。同时,解决在使用iframe跨域访问时,第三方cookie暂存转发问题。

  iframe安全嵌入方案

  iframe嵌入是一种快速的表示集成方法,具有以下三方面优点:

  1.iframe是一个全新的独立的宿主环境,用于隔离或者访问原始接口及对象,并能够原封不动地将嵌入的网页展现出来;

  2.如果有多个网页引用iframe,只需要修改iframe的内容,就可以实现调用的每一个页面内容的更改,方便快捷;

  3.重载页面时不需要重载整个页面,只需要重载页面中的一个框架页。

  例如,以vue工程为例,我们可以很轻松地嵌入iframe页面,轻松实现页面集成。

<template>

<div style="padding-top:10px;height:auto">

<iframe id='mainFrame' name='mainFrame' ref='mainFrame' :src="iframeUrl" target="_blank" height='1000px' frameborder="0" width="100%" ></iframe>

</div>

</template>

<script>

export default {

name: 'MyTestResource',

data() {

return{

iframeUrl: "",

}

},

created(){

this.iframeUrl = http://40. + "xxx-ev/ev/xxx/RedirectITA?toUrl=zycx&resouceCode=BBB&token=" + getLocalStorageToken()

},

  在嵌入第三方服务页面时,需要处理统一身份认证和保持登录状态的问题,下图所示为iframe安全注入方案示例。

  iframe安全注入服务流程为,用户在本方服务页面进行登录,本方服务向统一身份认证平台验证用户服务权限并得到本方服务令牌。

  当用户访问嵌入第三方服务的iframe页面时,本方服务向统一身份认证平台验证用户服务权限并得到第三方服务令牌,通过URL传送给第三方服务,第三方服务解析后向统一身份认证平台验证该用户权限令牌信息,若用户权限令牌信息正确则提供服务。

  其中第三方服务对iframe 嵌入可以通过如下配置方式实现。

  IE浏览器配置

  为了控制iframe嵌入的权限,需要在Headers里面加入X-Frame-Options字段,其有三种值可以配置,具体如下表格所示。

  Chrome、Edge浏览器配置

  经过测试发现X-Frame-Options 对Chrome及Edge浏览器不起作用,需要配置Content-Security-Policy: frame-ancestors 对iframe 页面嵌入进行安全控制。

  X-Frame-Options及 Content-Security-Policy 可以同时配置多个白名单,具体如下:

  Content-Security-Policy:

  frame-ancestors http://aaa.com http://bbb.com http://ccc.com

  X-Frame-Options:

  ALLOW-FROM http://aaa.com,http://bbb.com,http://ccc.com

  对于Nginx、apache 、IIS、tomcat 等不同的中间件有不同的配置方法,再次不再赘述,读者可以根据需要的场景进行不同配置。

  浏览器访问iframe问题

  我们在访问iframe 嵌入页面的时候,从本系统前端调用系统后台服务后,sendRedirect到第三方系统后台服务,对X-Frame-Options头进行了验证后,正常应该跳转到请求页面并对本系统浏览器进行内容响应。

  实际使用过程中却发生了奇怪的现象,第三方服务验证X-Frame-Options跨站验证后,302 跳转到了请求页面,又302 调用了登出接口,截止302 调用了登录接口,最终为用户响应了登录页面,如下图所示。

  猜测一下,问题可能出在以下几个方面:

  1.第三方服务调用统一安全认证服务失败,跳转登录页面,但是并没有安全认证失败的响应信息;

  2.第三方服务没有用户信息,跳转登录页面;

  3.第三方请求跳转页面时,对用户信息进行了基于浏览器信息的再次认证,失败并跳转登录页面。

  经过验证更换其他浏览器后,页面可以正常访问,说明统一安全认证无问题,且用户信息也验证正常,因此问题应该是第三种情况。

  浏览器访问iframe解决方案

  经过分析发现,Chrome内核51版本开始,其对于Cookie的控制新增加了一个SameSite属性,用来防止CSRF攻击和用户追踪。

  由第三方提供iframe嵌入页面服务的Cookie在Chrome内核被认为是第三方Cookie,浏览器默认会禁止第三方Cookie跨域传送,这里就涉及到浏览器Cookie 的SameSite属性。

  SameSite 可以有下面三种值:

  1.Strict仅允许一方请求携带 Cookie,即浏览器将只发送相同站点请求的 Cookie,即当前网页 URL 与请求目标 URL 完全一致;

  2.Lax允许部分第三方请求携带 Cookie;

  3.None无论是否跨站都会发送 Cookie。

  通过下面表格,我们可以清晰看到,不同请求类型下,SameSit属性对第三方Cookie 的响应方式。

  从上表可以看出,对大部分 web 应用而言,Post 表单、iframe、AJAX这三种情况从以前的跨站会发送三方Cookie,变成了不发送。

  故这三种情况跨站给第三方发送Cookie需要在设置的时候将SameSite设置为None。

  通过研究,我们发现可以通过配置Chrome 、Edge浏览器SameSite 属性可以有效解决该问题。

  低于91版本的Chrome浏览器

  Chrome中访问地址chrome://flags/ 搜索samesite 将same-site-by-default-cookies,和SameSite by default cookies这两项设置为Disabled后重启浏览器再运行项目即可解决。该设置默认情况下会将未指定SameSite属性的请求看做SameSite=Lax来处理。

  Chrome及Edge浏览器

  打开浏览器快捷方式的属性,在目标后添加

  --disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure ,点击应用、确定按钮,重启浏览器后生效。

  "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"

  通过执行脚本直接生成有效的快捷方式

chcp 65001

echo 正在创建桌面快捷方式,请勿关闭本窗口.

::设置程序或文件的完整路径(必选)

set Program=%cd%\chrome.exe

::设置快捷方式名称(必选)

set LnkName=SSSChrome

::设置程序的工作路径,一般为程序主目录,此项若留空,脚本将自行分析路径

set WorkDir=%cd%

::设置快捷方式显示的说明(可选)

set Desc=SSSChrome

if not defined WorkDir call:GetWorkDir "%Program%"

(echo Set WshShell=CreateObject("WScript.Shell"^)

echo strDesKtop=WshShell.SpecialFolders("DesKtop"^)

echo Set oShellLink=WshShell.CreateShortcut(strDesKtop^&"\%LnkName%.lnk"^)

echo oShellLink.TargetPath="%Program%"

echo oShellLink.Arguments="--disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure"

echo oShellLink.WorkingDirectory="%WorkDir%"

echo oShellLink.WindowStyle=1

echo oShellLink.Description="%Desc%"

echo oShellLink.Save)>makelnk.vbs

echo 桌面快捷方式创建成功!

makelnk.vbs

del /f /q makelnk.vbs

exit

goto :eof

:GetWorkDir

set WorkDir=%~dp1

set WorkDir=%WorkDir:~,-1%

goto :eof

  从下图我们可以看到,响应请求,由原来的4个302 后跳转到登录页面变为2个302 跳转后正常进入功能页面,解决了请求第三方iframe时不发送Cookie 造成第三方服务认证通过跳转登录页面的问题。

  总结

  本文介绍了iframe内联框架,帮助您安全地嵌入iframe页面并提高页面集成效率和复用率,达到代码的高复用和良好的用户体验。

  请求第三方iframe时,能够对iframe进行请求头验证及统一安全验证,实现iframe页面安全嵌入。针对浏览器访问第三方iframe时存在的第三方Cookie 不能正常发送问题,提供了可行的解决方案,可以为页面嵌入使用方面提供有效的借鉴。

最后:

1)关注+私信回复:“测试”,可以免费领取一份10G软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享!,其中包括了有基础知识、Linux必备、Mysql数据库、抓包工具、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试等。

2)关注+私信回复:"入群" 就可以邀请你进入软件测试群学习交流~~

SVG(Scalable Vector Graphics)是一种基于XML的2D矢量图形格式,可以实现图像的无损缩放和高清晰度显示。在HTML中嵌入SVG图像,可以使网页更加生动有趣,提高用户体验

<svg width="54" height="54" class="c-nav--footer__svgicon c-slackhash" viewBox="0 0 54 54" xmlns="http://www.w3.org/2000/svg">
<g fill="none" fill-rule="evenodd">
<path d="M19.712.133a5.381 5.381 0 0 0-5.376 5.387 5.381 5.381 0 0 0 5.376 5.386h5.376V5.52A5.381 5.381 0 0 0 19.712.133m0 14.365H5.376A5.381 5.381 0 0 0 0 19.884a5.381 5.381 0 0 0 5.376 5.387h14.336a5.381 5.381 0 0 0 5.376-5.387 5.381 5.381 0 0 0-5.376-5.386" fill="#44BEDF">
</path>
<path d="M53.76 19.884a5.381 5.381 0 0 0-5.376-5.386 5.381 5.381 0 0 0-5.376 5.386v5.387h5.376a5.381 5.381 0 0 0 5.376-5.387m-14.336 0V5.52A5.381 5.381 0 0 0 34.048.133a5.381 5.381 0 0 0-5.376 5.387v14.364a5.381 5.381 0 0 0 5.376 5.387 5.381 5.381 0 0 0 5.376-5.387" fill="#2EB67D">
</path>
<path d="M34.048 54a5.381 5.381 0 0 0 5.376-5.387 5.381 5.381 0 0 0-5.376-5.386h-5.376v5.386A5.381 5.381 0 0 0 34.048 54m0-14.365h14.336a5.381 5.381 0 0 0 5.376-5.386 5.381 5.381 0 0 0-5.376-5.387H34.048a5.381 5.381 0 0 0-5.376 5.387 5.381 5.381 0 0 0 5.376 5.386" fill="#ECB22E">
</path>
<path d="M0 34.249a5.381 5.381 0 0 0 5.376 5.386 5.381 5.381 0 0 0 5.376-5.386v-5.387H5.376A5.381 5.381 0 0 0 0 34.25m14.336-.001v14.364A5.381 5.381 0 0 0 19.712 54a5.381 5.381 0 0 0 5.376-5.387V34.25a5.381 5.381 0 0 0-5.376-5.387 5.381 5.381 0 0 0-5.376 5.387" fill="#E01E5A">
</path>
</g>
</svg>