① 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、氨氮、硝氮、亞硝氮、總磷等數據進行實時的監測，保障數據獲取的准確性。旅館業前端採集系統在登錄的表單中添加記住密碼勾選框即可保存登陸賬號密碼。前端採集系統前端採集系統是指系統前端採集音視頻信息的設備。