最近在忙著實作我的一些小項目，沒有上來發文，但還是一直學習JS，
累積滿多經驗，也累積不少疑問。之前站長阿川有跟我提到相關話題，也就是UJS，想說把它拿過來聊一聊。
剛好最近弄的東西，跟這個也有一些關聯性。
html與JS的交互關係。
Inline JavaScript是什麼呢？
就把JS寫在html裡面的一種手段，也就是onclick那些東西，在自學教材會學到唷：））。
其中也有個東西叫做JavaScript pseudo-protocol，他好像有點像是給一個js的前綴，
讓瀏覽器讀取html的時候知道要開始讀取JS了，用法如：
<a href="javascript:alert(1)">my website</a>
這樣子的作法都讓JS侵入到html裡面，也就是行為跟結構沒有分離。
是否要UJS，站長上次有提到這可以看專案大小來區分，這篇閒聊開起來可以提供更多細節。
不過我不打算就此結束文章，我要額外分享與XSS相關的內容。
XSS其實是CSS，跨站指令碼Cross Site Script的意思，只是因為縮寫重複CSS樣式（Cascading Style Sheets ）所以用X代替。
簡單理解它就是一種攻擊手段，讓別人網站上執行我的代碼。
有趣的事情來了，那html跟JS交互關係跟XSS又有什麼關聯呢？
想像一下，當今天小明要做一個討論區，讓使用者用html編輯打文章，就必須小心有人會放一些JS的代碼。
小明想說，我要過濾<script>標籤來保證他們乖乖地寫html。
請問這樣子是否就安全了呢？
答案是否定的，這時候使用Inline JavaScript會發生什麼狀況？
試想一下因為小明沒有CSP相關設定，防止使用者偷偷塞JS到html裡面，導致小明的壞朋友大胖，
可以直接寫一個<img src=x onerror="alert(1)">在留言區裡面，
完全沒有使用到<script>標籤，卻也能造成XSS。
關於防禦：
CSP
設定嚴格一點，可以阻止很多XSS，舉例來說文章一開始有href="javascript:alert(1)"，
可以設定href後面只能接上http開頭的東西。
WAF
他是Web Application Firewall 的簡稱，中文通常叫作「網站應用程式防火牆」
可以建立及管理避免網際網路威脅的規則，包括IP 位址、HTTP 標頭、HTTP 主體、URI 字串、跨網站命令檔(XSS)、SQL 隱碼攻擊及其他OWASP 定義的漏洞。
自己建立fliter
自己過濾也是可行的（不建議），把字串符碼都轉成HTML Entities，例如把 (<)寫成 < or <
，透過這樣的過濾render出來的就不會是指令了。
為什麼不建議，是因為你過濾的東西有可能會被double encoded URL之類的手法繞過。
或是你覆蓋了document.write，以為安全了，但是我用孿生函數(twin function)的document.writeIn你可能就忘了過濾。
這剛好就是我最近在研究的東西。
相關討論問題：
1.對於文章的內容，有沒有什麼錯誤呢？或相關名詞想法想補充？
2.是否要UJS的實際使用，有哪些想法？或是有什麼經驗？
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
UJS 這個名詞，我在前端社群其實沒有看過
查了一下，好像只有 Rails 社群會使用這個名詞
一般來說，軟體產業，比較常講 separation of concerns（關注點分離）
用來說明：將不同概念的程式部份，分開來，會讓程式比較好維護
實務上來說，html 跟 js 程式碼，通通混在一起，當然會很難讀、很亂
不過，在 React 社群，大家所寫的 jsx，很多時候看起來又很像是把 html 跟 js 混在一起了
所以這個部份有點 tricky，在 React 社群，大家在乎的 separation of concerns 其實是「state 與 side-effects」而不是「行為與結構」
這相關的概念很進階，我這邊先不詳談，或許有機會再專文介紹
後記：看得出來資訊量頗大的，這幾天的確很充實，都在注意XSS相關資料ㄎㄎ。
希望不會太分散，如果主題會太發散，未來可以再開一篇XSS的（？
這篇就可以專注聊某一個部分～～