macOS 建立laravel專案

 先安裝brew

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

因為安裝的時候路徑沒安裝好，所以要額外設定

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/jiangyuchun/.zprofile

eval "$(/opt/homebrew/bin/brew shellenv)"

經brew 裝php

brew install php@8.0

如果要在當下目錄run，要把設定寫到.zhrc

echo 'export PATH="/opt/homebrew/opt/php@8.0/bin:$PATH"' >> ~/.zshrc

echo 'export PATH="/opt/homebrew/opt/php@8.0/sbin:$PATH"' >> ~/.zshrc

For compilers to find php@8.0 you may need to set:

export LDFLAGS="-L/opt/homebrew/opt/php@8.0/lib"

export CPPFLAGS="-I/opt/homebrew/opt/php@8.0/include"

看php版本

php -v    //PHP 8.0.19

經brew裝composer

brew install composer

把composer 的指令簡化

export PATH="$PATH:$HOME/.composer/vendor/bin"

用composer 來安裝Laravel

composer global require laravel/installer

brew安裝node.js

brew install node    //Laravel 前端部分是需要nodejs的

建立一個Laravel項目試試

cd ~/php

composer create-project laravel/laravel test_0608

嘗試啟動

cd test01

php artisan serve

瀏覽 http://127.0.0.1:8000

參考網站

https://adminhk.com/laravel%E6%95%99%E5%AD%B8%E7%AD%86%E8%A8%98-01-laravel8-%E5%85%A5%E9%96%80%E5%8F%8A%E7%92%B0%E5%A2%83%E5%AE%89%E8%A3%9D/

GCP work Laravel

Step 1：啟動服務
GCP主選單 > App Engine > 資訊主頁

 

Step 2：開始進行 App Engine 的基礎設置
語言：PHP
開啟 Cloud Console

Step 3：使用 Composer 下載 Laravel
composer create-project --prefer-dist laravel/laravel laravel
建立一個乾淨的 Laravel 專案，最後面的 laravel 可以改成你喜歡的名稱

Step 4：設定專案及建立 GAE 用的設定檔案
cd laravel/
cat .env
把螢幕上顯示的 APP_KEY 存下來備用

vim app.yaml
打開程式碼編輯器，並將左圖基礎設定貼上

Step 5：測試一下有沒有遺漏的地方
php -S localhost:8080 -t public
打開 PHP 本身的開發用解析器 (小型伺服器)

點選右上角的網頁預覽

Step 6：開始發佈應用程式吧
gcloud app deploy
預設網址為 https://[專案ID].appspot.com
可以打開看一下

https://laraveltest-349802.appspot.com/

參考網址：https://orangecat.tw/google-app-engine-app-example-with-laravel/

網站運作原理

 

Step 1：找到想去網站的網址

    在瀏覽器輸入想搜尋的網址。

Step 2：找到網址的 IP

    透過 DNS 伺服器才能知道這個網址所對應到的 IP 位置。

Step 3：請求網站伺服器存取

    請求存取該網站的資料。

Step 4：開始傳送網站資料

    當網站伺服器允許存取後，接著就會開始傳送最重要的東西，也就是該網站的資料啦！網站資料會以封包的形式做傳遞，並且透過網際網路傳送到你正在使用的瀏覽器。

Step 5：瀏覽器建構網站

    當網站伺服器把資料傳給瀏覽器後，瀏覽器就會像用磚塊蓋房子一樣，把資料一個一個解析並建構，最後就變成我們看到網站的樣子啦！

Apache vs Nginx

Apache - 支援模組多，效能穩定，Apache本身是靜態解析，適合靜態HTML、圖片等，但可以通過擴充套件指令碼、模組等支援動態頁面等。

優點： 

1. 模塊比 Nginx 豐富
   
2. 兼容性和穩定性都是非常強
3. 處理動態請求比 Nginx 更有優勢

缺點：

1. 速度、性能不及其他輕量級web服務器，並且消費內存較高
2. 消耗的cpu等服務器資源比較大

Nginx - 是一個高效能的HTTP和反向代理伺服器，同時也是一個IMAP/POP3/SMTP 代理伺服器。其特點是佔有記憶體少，併發能力強，易於開發，部署方便。Nginx 支援多語言通用伺服器。

優點

1. 輕量級，比apache 佔用更少的內存及資源
2. 抗併發，nginx 處理請求是異步非阻塞的
3. 處理靜態文件，索引文件以及自動索引，打開文件描述符緩衝

缺點

1. 處理動態請求是雞肋，不如Apache

建議方案：

Apache 後臺服務器（主要處理php及一些動態請求）；Nginx 前端服務器（高併發請求、靜態資源、負載均衡、反向代理和前端Cache等）。

Laravel 目錄

app
app目錄底下包含了整個網站大多數的核心程式，之後我們所寫的程式大多都會丟進來這個資料夾中，其中包含了Controller以及Model的部分。
app/Http/Controllers

resources
主要就是包含了View，也就是網頁的前端。

routes
處理使用者存取網站的要求。最常用到的就是web.php。

config
設定檔，包含前面提到的app, database，還有像是session, cache, mail等等的設定。

database
主要包含3個部分:

1. Migration – 用於建立資料表，並記錄每一次資料表的更新，讓資料庫也可以進行版本控制。
2. Seed – 產生假資料，可以呼叫Factory來大量產生
3. Factory – 負責如何產生假資料的邏輯，然後給Seed使用

public

專門放公開的檔案，包含網站的index文件，還有CSS, JavaScript, Image等。

bootstrap

這個bootstrap是去進行laravel的初始化，載入相關程式。另外也包含了cache的資料夾，用來提升網站運作的效能。

tests

用來放自動化測試的程式。

storage

這個目錄會包含編譯過後的Blade templates(後面會提到), 檔案式的session, cache以及log紀錄等各式各樣laravel自己產生的檔案。

vendor

從composer安裝的套件，都會在vendor裡面。同時這個資料夾在版本控制時會被排除，不會一起被同步(檔案太多)。

SameSite cookie

踩雷：
因為登入資訊存在cookie中，smartpay付款完成後，導回指定頁面時，抓不到登入狀態的cookie，導致後續判斷有問題。

Chrome 80 之後的版本，預設的 Cookie 設定將會無法跨站存取 Cookie 值，若想要允許 Cookie 跨網站存取的話(SameSite = None)，需要使用 HTTPS 才可以。

Cookie SameSite 有三種設定：

Strict：最嚴謹，完全禁止第三方 Cookie，跨網域時，任何情況下都不會發送 Cookie。只有與目前網頁網址一致才能發送。

Lax (default)：稍微放寬，大多數情況也不發送第三方 cookie ，但Ｇet請求可以。

None(需有 HTTPS 搭配，否則一樣等同 Lax)：允許跨網域存取。

 關閉same-site-cookie default：

 chrome://flags/

參考：
https://web.dev/samesite-cookies-explained/
Chrome 80 後針對第三方 Cookie 的規則調整 (default SameSite=Lax)

同源政策 Same-origin policy

同源政策是在browser執行的。

同源定義：

同網域（Domain）

同通訊協定：HTTP, HTTPS, FTP

同連接埠號（Port）

目的：

防止惡意網站竊取數據。

限制：

Cookie、LocalStorage 和 IndexDB 無法存取。

DOM 無法獲得。

AJAX 請求不得發送。

Session vs Cookie

Session： 

特性：

• 第一次訪問時， Server 為 Client 創建一個 session-id， 並把 session-id 回傳，存在 Client 的 Cookie中。
• 下次訪問時，Client 會帶著 Cookie訪問，Server會檢查有沒有帶session-id。若有，會找出對應的文件，把訊息讀取出來 ，若沒有，會建立一個session-id。
• session_destroy()，並清除cookie，這樣 Client、 Server就沒關係了。

優點：

• 存於 Server，安全性高。

缺點：

• 效能問題，佔 Server記憶體資源 (每個用戶都要有自己的 session 文件，光找文件就耗不少資源)
• Cookie 沒開的話， Session也不能用 (透過 php.ini 設定 session.use_trans_sid = 1，這樣 sessionID 就可以透過網址的方式傳回 server ，不用透過 cookie )。

失效時機：

    與php.ini設置相關 => session.cookie_lifetime = 0  //0表示cookie存活至瀏覽器關閉

                                  session.gc_probability = 1

                                  session.gc_divisor = 100

                                  session.gc_max_lifetime = 1440 //預設session逾時為24分鐘

檔案存放位置：

    與php.ini設置有關 => session.save_handler = file

Cookie：

特性：

1. Cookie size 限制: 根據 RFC-2965 的規定，一個 Cookies 最大可以是 4096 bytes，而一個 domain 最多只能有 20 cookies。
2. 佔據網路流量: 由於每次 request 都必須將 Cookie 的資料放在 headers，所以當 Cookie 的資料變大時，request 也會跟著變大，過大的 request 會影響網路傳輸的速度。 
3. Cookie 資料可被使用者竄改: 由於 Cookies 存在 browser 中，所以使用者可透過瀏覽器查看 Cookie 的資料以及其結構，當使用者任意竄改 Cookies 的資料時可能會導致資料外洩或者系統流程出錯。

Cookies 只能儲存結構簡單，容量小且無意義的資訊，且必須符合『同源政策』。