① web前端跨域的一些解决方案
没有归纳之前对跨域的一些说法是模糊的，什么jsonp啊，跨域原理啊，心里只有一个大概的说法，知道这个东西，然后用的时候直接网络Ctrl+C，后来闲下来决定整理一波这些知识点，需知其所以然。
那么，其实这是浏览器对我们的一种保护机制，把坏人挡在门外。那么，问题来了，我们怎么确定门外的人到底是好人还是坏人呢？浏览器关上了坏人的一扇门，留给了我们好人一扇窗。
JSONP跟JSON没有关系..就好像JavaScript和Java一样
浏览器对script、img（这些标签的请求方式都是 GET ，所以jsonp不支持 POST ）这种标签没有限制，我们就可以这样干
因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。
服务器端对于CORS的支持，主要就是通过设置 Access-Control-Allow-Origin 来进行的。如果浏览器检测到相应的设置，就可以允许Ajax进行跨域的访问。 更多有关跨域资源共享 CORS 的知识
浏览器中可以查看对应的响应头，举个例子，如下
服务端允许CORS，服务端需要针对接口设置的一系列响应头 (Response Headers)
1.简单请求
目前大多数情况都采用这种方式。简单请求只需要设置 Access-Control-Allow-Origin 即可。满足以下两个条件，就属于简单请求。
2.非简单请求
非简单请求会发出一次预检测请求，返回码是204，预检测通过才会真正发出请求，这才返回200。来看栗子：
非简单请求需要根据不同情况配置不同的响应头，一系列响应头配置项见上方
这个说法相信不陌生，我们依然使用前端域名请求，然后有一个 中介商---代理 把这个请求转发到真正的后端域名上，那也就不存在跨域问题了。
比较普遍的Nginx，简单的配置一下就可以了。了解更多的配置信息： nginx详解
然后前端这边的请求地址是 http://localhost:9099/api/xxx ,然后Nginx监听到地址是 localhost:9099/api 的请求，就帮我们转发到真正的服务端地址 http://.com
CORS与JSONP的使用目的相同，但是比JSONP更强大。JSONP只支持GET请求，CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器，以及在服务端同意jsonp方式时，可以向不支持CORS的网站请求数据。Nginx可以说是最方便的，不过需要部署Nginx才行，需要对服务器有一定的理解，不太适合刚入门的同学，当然也可以请后台同学帮忙部署。
window.postMessage(data,origin) 是 HTML5 的一个接口，专注实现不同窗口不同页面的跨域通讯。
现在是这么一个情况,由于同源策略的限制下， a.html 不能操作iframe( b.html )里面的dom，那么使用postMessage就可以解决这一情况
然后 b.html 页面通过message事件监听并接受消息:
这种方式只适合主域名相同，但子域名不同的iframe跨域。
比如主域名是 http://.com/:8888 ，子域名是 http://child..com/:8888 ，这种情况下给两个页面设置相同的document.domain即document.domain = .com 就可以访问各自的window对象了。
前端跨域整理
不要再问我跨域的问题了
② 用户系统设计(上)前端设计和多平台账号打通
前言
用户系统是很多产品最基础的构成之一，但是越是基础越是开源设计想要完善也更难。在设计用户系统的时候，首先想到的关键词是注册和登录。但并不是有这两者就足够了，更加完善用户系统本身还需要考虑：多平台账号打通，同平台账号之间绑定与解绑，账号安全等及需要怎样的前端设计才是满足这个产品本身定位和用户操作的设计。
用户系统的实现简单来说有两种方式：1、自己构建用户系统；2、用第三方授权。第三方授权获得的用户信息有限且受制于人，而自己构建用户系统研发及用户使用成本均不如第三方授权。所以更多的是两者并存，相互补充。
在定义服务端字段或需求若有不完善和不专业的地方，希望大家多提意见，共同完善。
一、总结需求
1.用户系统基本注册／登录功能及前端页面设计
2.多平台账号打通，即在单一app注册的用户，能够使用此账号登陆系统内所有app
3.用户相对独立，对于单一app来说用户身份唯一
二、前端设计
登陆注册主流设计有三种（原型如下）
1. 账号密码优先
账号密码优先是最常见的一种登录注册设计，适用于普遍场景，鼓励用户用注册方式登录，有利于产品引导用户完善更多的资料，留存自己的用户信息。例如知乎是以账号密码登录为最优先，且会隐藏第三方授权登录。现在的账号密码登录都会以用户注册方式代替系统生成的userid作为账号。纯账号密码登录是较为早期的设计，例如早期qq和飞信。
2. 手机号快捷登陆优先
手机号快捷登陆，也叫免密登录／短信验证码登录，适用于用户不登录能够完成大部分行为，只有在某种场景下必须获得用户身份时才需要用户登录，且此时用户的想要完成的行为是被要求登录操作打断的。常见的如团购类产品，用户在应用内进行了商品的浏览、筛选、添加到购物车，当要进行最后一步付款操作时，发现未登录。这时繁琐的注册或者登录都有可能导致这笔订单甚至这个用户的流失。所以这时获取用户身份的方式一定要尽可能便捷。
3. 第三方授权登陆优先
第三方授权登陆，适用于对用户资料和权限要求不高快速解约开发成本的产品。建议在应用构建用户系统的前期可以首先接入第三方，快速的实现登录功能。但是若想建设自身关系链还是需要完善自己的用户系统。
用户资料实际也属于用户系统等设计的内容。是否要增加此项的判断原则是根据这个产品对用户资料的需求程度决定用户注册时是否要增加资料填写页，资料填写页是强制阻断性的还是可跳过的，必填的资料项有哪些，希望填的有哪些。例如是需要关系链的那么注册的时候就应该强制用户去填写资料设置必要的昵称和头像，这样的用户对于此类应用来说才属于有效用户，不然在app内用户点进资料页，全是系统自动生成的垃圾信息，对于建设关系链和留存伤害较大。
交互细节上又可以延伸用户进行注册或登录需要几个步骤？这些步骤是在一个页面上承载还是一步一个页面以多页面去承载？单一页面承载的优势是用户能够有很清楚的预期，他完成注册需要进行哪些操作，但是劣势是一个页面承载过多信息显得杂乱，操作的次序也会不明确；多页面承载的劣势是用户对完成注册的具体行为没有完整预期，更容易跳出，优势是页面整洁并且路径单一，能引导用户完全按照通畅的预设路径进行。我个人更推荐后者，因为用户预期可以用页码／步骤管理用户预期。
下面是我根据我们产品的定位和需求设计的用户登录／注册系统原型：如上所说，我设计的用户系统是需要承载多产品的，所以我设计融合账号密码登录和手机号快捷登录两种方式，以用户出发需要登录的场景去切换展现在用户面前的是哪一种。
补充一些贴心的小点：
1.申请读取本机号码权限，并帮用户填写
2.申请读写短信权限，获取到验证码后自动填写并点击下一步
3.应该前置到提醒：上次登录方式，合法的手机号，正确的图形验证码等等
三、服务端设计
很多产品，特别是没有技术背景的产品不会去接触和设计服务端需求，实际上我自己日常工作中接触服务端需求也并不多，并不是说产品要负责设计一个完善的用户系统服务端，而是要学会以服务端同事能懂的方式表达清楚自己的诉求，两边对功能的实现不会有太多的偏差，这是产品设计服务端目的所在。
简单的用户系统服务端的基本功能需求为：判断账号身份（注册/未注册），账号身份生成（新用户分配id），账号密码验证；这里要设计的并不满足于注册登录，需要考虑多平台账号打通的用户系统并且要和在打通情况下单一平台或多个平台之间，用户的多个账号之间绑定于解绑。现在先说一下多平台账号打通需要考虑哪些问题：
1.用户系统身份的创建，因为我们是多平台的系统，所以用户身份只能纳入手机号注册的用户，若第三方授权注册的也算用户系统用户，在账号绑定的那一关则会出现混乱；
2.实现多平台账号打通，要实现多平台账号打通，即所有接入多平台都能够查询到此用户身份；
3.平台间用户身份独立，要实现平台间用户身份独立，则需要在用户系统用户身份的基础上创建一个平台的用户身份；
(一) 用户系统多平台打通
名词解释
1)Appid：接入用户系统时首先分配，用于区别接入的各个app；
2)Unionid：用户手机注册时，由用户系统根据手机号创建，在用户系统作为用户唯一身份标识；
3)Appuserid：用户注册时，由app服务端根据union或者第三方授权的openid创建，在app内作为用户唯一的身份标识；
基本原则
1)手机号作为用户系统账号的注册的唯一途径，根据手机号在用户系统服务端创建并保存unionid；app服务端根据unionid创建并保存appuserid，且将unionid对应保存；
2)用户系统同一unionid可对应不同的appuserid
3)使用第三方openid授权的注册用户不计入用户系统仅存在app服务端作为单app用户，即unioid为空只生成appuserid；第三方授权包括微博微信，QQ，Facebook，Twitter
1. 主线流程图
手机号注册主流程为：
用户注册时，用户系统服务端需要验证手机号＋验证码是否为真，此手机号是否已有对应unionid；若有提示已注册，请登录；若无创建对应unionid，app服务端根据unionid创建appuserid。至此成功生成了用户系统身份及当前app用户身份。
手机号登陆主流程为：
用户登录时，用户系统服务的验证手机号＋密码是否为真，此手机号是否有对应unionid，若有，则说明此用户有用户系统身份。
还需要app服务端需要查询是否有对应的appuserid，若有说明此用户有此app身份，直接用其appuserid登录；若无则说明是用户系统内其他联合app注册用户根据unionid创建此app的用户身份，至此登录成功。
用户系统是大多数app都会有多构成，单一的用户系统也并不那么复杂，但是若要构建产品矩阵进行多平台间的用户打通，加上帐号绑定与解绑，并不是一时半会能够想清楚的需求，若大家感兴趣为会继续补充帐号绑定和账号安全产品应该关心和设计的事情。谢谢：）
③ Web前端中关于url、href、src的知识汇总
今天小编要跟大家分享的文章是Web前端中关于url、href、src的知识汇总。熟悉web前端的小伙伴们一定不会对这三个内容陌生。但是对于刚刚接触web的小伙伴肯定不是很了解，今天小编就败漏租为大家准备了这篇文章让我们一起来看一看关于url、href、src的知识汇总。
一、URL的概念
统一资源定位符(或称统一资源定位器/定位地址、URL地址等，英语：UniformResource
Locator，常缩写为URL)，有时也被俗称为网页地址(网址)。如同在网络上的门牌，是因特网上标准的资源的地址(Address)。
二、URL的格式
2.1标准格式
协议类型:[//服务器地址[:端口号]][/资源层级UNIX文件路径]文件名?查询
2.2完整格式
协议类型:[//[访问资源需要的凭证信息@]服务器地址[:端口号]][/资源层级UNIX文件路径]文件名?查询
其中【访问凭证信息@;:端口号;?查询;#片段ID】都属于选填项。
三、URL的语法规则
比如网址#/html/index.asp，必须遵守以下的语法规则：
scheme://host.domain:port/path/filename
3.1说明
(1)scheme-定义因特网服务的类型。最常见的类型是http(2)host-定义域主机(http的默认主机是www)
(3)domain-定义因特网域名，比如w3school.com.cn(4):port-定义主机上的端口号(http的默认端口号是80)
(5)path-定义服务器上的路径(如果省略，则文档必须位于网站的根目录中)。(6)filename-定义文档/资源的名称
3.2URLSchemes
以下是其中一些最流行的scheme：
Scheme访问用于...
http超文本传输协议以http://开头的普通网页。不加密。
https安全超文本传输协议安全网页。加密所有信息交换。
ftp文件传输协议用于将文件下载或上传至网站。
file您计算机上的文件。
四、URL的类型
4.1绝对URL
绝对URL(absoluteURL)显示文件的完整路径，这意味着绝对URL本身所在的位置与被引用的实际文件的位置无关。
4.2相对URL
相对URL(relativeURL)以包含URL本身的文件夹的位置为参考点，描述目标文件夹的位置。
一般来说，对于同一服务器上的文件，应该总是使用相对URL，它们更容易输入，而且在将页面从本地系统转移到服务器上时更方便，只要每个文件的相对位置保持不变，链接就仍然是有效地。
以下为建立路径所使用的几个特殊符号，及其所代表的意义。
(1).：代表目前所在的目录，相对路径。如：文本或
(2)..：代表上一层目录，相对路径。如：文本或
(3)../../：代表的是上一层目录的上一层目录，相对路径。如：
(4)/：代表根目录，绝对路径。如：[文本](/abc)或
五、href的概念
5.1规范解释
href(Hypertext
Reference)指定网络资源的位置，从而在当前元素或者当前文档和由当前属性定义的需要的锚点或资源之间定义一个链接或者关系。
5.2通俗理解
href目的不是为了引用资源，而是为了建立联系，让当前标签能够链接到目标地址。
六、src的概念
source(缩写)，指向外部资源的位置，指向的内容将会应用到文档中当前标签所在位置。
七、href和src的区别
7.1请求资源类型不同
(1)href指向网络资源所在位置，建立和当前元素(锚点)或当前文档(链接)之间的联系。
(2)在请求src资源时会将其指向的资源下载并应用到文档中，比如JavaScript脚本，img图片;
7.2作用结果不同
(1)href用于在当前文档和引用察兆资源之间确立联系;
(2)src用于替换当前内容;
7.3浏览器解析方式不同
(1)若在文档中添加，浏览器会识别该文档为CSS文件，就会并行下载资源并且不会停止对当前文档的处理。这也是为什么建议使用link方式加载
CSS，而不是使用@import方式。
(2)当浏览器解析到
，会暂停其他资源的下载和处理，直到将该资源加载、编译、执行完毕，图片和框架等也如此，类似于将所指向资源应用到当前内容。这也是为什么建议把js
脚本放在底部而不是头部的原因。
八、link和@import的区别
两者都是外部引用CSS的方式，但是存在一定的搜州区别：
(1)link是XHTML标签，除了能够加载CSS，还可以定义RSS等其他事务;而@import属于CSS范畴，只可以加载CSS。
(2)link引用CSS时，在页面载入时同时加载;@import需要页面完全载入以后再加载。
(3)link是XHTML标签，无兼容问题;@import则是在CSS2.1提出的，低版本的浏览器不支持。
(4)link支持使用Javascript控制DOM改变样式;而@import不支持。
以上就是小编今天为大家分享的关于Web前端中关于url、href、src的知识汇总的文章，希望本篇文章能够对正在从事web学习和工作的小伙伴们有所帮助，想要了解更多web相关知识记得关注北大青鸟web培训官网哦~
作者：WEBING
#/a/1190000013845173
*声明：内容与图片均来源于网络(部分内容有修改)，版权归原作者所有，如来源信息有误或侵犯权益，请联系我们删除或授权事宜。
④ 在前端方面有哪些识别唯一设备或用户的方法
UDID的全称是Unique Device Identifier，顾名思义，它就是苹果IOS设备的唯一识别码，它由40个字符的字母和数字组成。在很多需要限制一台设备一个账号的应用中经常会用到。在iOS5中可以获取到设备的UDID，后来被苹果禁止了。
IDFA（identifierForIdentifier）
广告标示符，适用于对外：例如广告推广，换量等跨应用的用户追踪等。
是iOS 6中另外一个新的方法，提供了一个方法advertisingIdentifier，通过调用该方法会返回一个NSUUID实例，最后可以获得一个UUID，由系统存储着的。不过即使这是由系统存储的，但是有几种情况下，会重新生成广告标示符。如果用户完全重置系统（(设置程序 -> 通用 -> 还原 -> 还原位置与隐私) ，这个广告标示符会重新生成。另外如果用户明确的还原广告(设置程序-> 通用 -> 关于本机 -> 广告 -> 还原广告标示符) ，那么广告标示符也会重新生成。关于广告标示符的还原，有一点需要注意：如果程序在后台运行，此时用户“还原广告标示符”，然后再回到程序中，此时获取广 告标示符并不会立即获得还原后的标示符。必须要终止程序，然后再重新启动程序，才能获得还原后的广告标示符。
在同一个设备上的所有App都会取到相同的值，是苹果专门给各广告提供商用来追踪用户而设的，用户可以在 设置|隐私|广告追踪 里重置此id的值，或限制此id的使用，故此id有可能会取不到值，但好在Apple默认是允许追踪的，而且一般用户都不知道有这么个设置，所以基本上用来监测推广效果，是戳戳有余了。
注意：由于idfa会出现取不到的情况，故绝不可以作为业务分析的主id，来识别用户。
IDFV（identifierForVendor）
Vindor标示符，适用于对内：例如分析用户在应用内的行为等。
是给Vendor标识用户用的，每个设备在所属同一个Vender的应用里，都有相同的值。其中的Vender是指应用提供商，但准确点说，是通过BundleID的DNS反转的前两部分进行匹配，如果相同就是同一个Vender，例如对于com.somecompany.appone,com.somecompany.apptwo
这两个BundleID来说，就属于同一个Vender，共享同一个idfv的值。和idfa不同的是，idfv的值是一定能取到的，所以非常适合于作为内部用户行为分析的主id，来标识用户，替代OpenUDID。
注意：如果用户将属于此Vender的所有App卸载，则idfv的值会被重置，即再重装此Vender的App，idfv的值和之前不同。
⑤ 旅馆业前端采集系统怎么永久保存登陆账号密码
在登录的表单中添加记住密码勾选框即可。前端采集系统：前端通过连接摄像头、各类传感器，对产污设备、排污设备、排污口、周边大气等环境进行监控，实时监测流速、流量、PH值、COD、氨氮、硝氮、亚硝氮、总磷等数据进行实时的监测，保障数据获取的准确性。旅馆业前端采集系统在登录的表单中添加记住密码勾选框即可保存登陆账号密码。前端采集系统前端采集系统是指系统前端采集音视频信息的设备。