@rustkeyboard 圖片掛了，你可以看看 book.php?id=8
你查查數據庫這條文字的更新時間和更新記錄吧。
POST:http://idoc.codespeaking.com/admin/api.php
did:17
node_type:0
article_content:123" onload="alert(/again/)
act:save_article_content
prid:32


did->17 是文字的 ID，這個沒問題
prid->32 是我自己伪造的。
ID：17 的這文章並非我添加的，但是我能直接修改刪除，你覺得有問題嗎？

https://i.imgur.com/wfBOgTp.png https://i.imgur.com/9mwiV6W.png
還是昨天的問題，還未修復。

順便看了下代碼，知道 sql 語句為何沒有使用添加人的 ID 來進行篩選了。
如果你真的是想做好這個程序，這個懶是偷不了的。
添加個中間表，處理項目權限問題，修改刪除的時候根據這個中間表進行權限的判斷。
如果說項目權限的問題你打算後期做，那麼前期你只能通過項目所屬用戶 ID 來判斷是否該用戶，即不可支持多用戶模式（並且暫時前端還沒發現可以授權他人管理，但是後端的代碼卻寫了一半...）。

30L 為什麼說教科書式的安全漏洞，是因為稍微有基礎（ HTTP、PHP 基礎）的都會合理規避這些潛在的問題。
切記 “用戶提交的數據是不可信的！”

@rustkeyboard
[url]http://idoc.codespeaking.com/book.php?id=8},function(a){});alert(123123);var%20a%20=%20({[/url]
CSRF 漏洞

老實說，如果您覺得聽不進去就算了，
先拋開體驗度和功能，這套代碼要正式使用還有一大堆問題需要修復。
而且看你開源的代碼，感覺應該屬於練手系列吧？
你有個 api.php 的文件，是只處理後台的請求？然後前台的請求就分散各個頁面單獨處理，
這樣的話對於你後期擴展功能會很不方便。
另外看你 book.php 這個頁面，其實沒必要 BOOK.PHP 執行一次查詢，然後再通過 AJAX，獲取另一次查詢的結果。與其這樣還不如直接在 book.php 里完成查詢，或 BOOK.Php 改為靜態，內容通過一次 ajax 進行查詢回來？
還有 timestamp 這個類型真的不建議使用，項目大了之後到 2038 年就後悔死自己了。

@rustkeyboard

> $pids = $_SESSION['pids'];
> $prid = $_REQUEST['prid'];
> if ( strpos($pids, $prid) === false ) {
> echo json_encode(['status'=>'FAIL', 'msg'=>'非法的操作!']);
> exit;
> }

如沒猜錯你是想判斷這兩個 ID 是否相等，不相等就沒權限處理吧？
但你這裡的 strpos 用的我是相當迷茫.....
查找 登錄 ID 在提交 ID 首次出現的位置。
那麼假設登錄 ID 固定為 12，當我需要改用戶 ID 為 13 的文章，
我只需要提交 prid=1 或者 2 那樣我就能繞過去了.

為什麼你不用 === 來判斷？ $pids == $prid ,這樣不是更好嗎？

然後突然間我發現另一個問題，
為什麼你會在這裡進行判斷，
就算你用==來判斷，最終執行 SQL 的時候，還是成功執行了，為什麼不在 SQL 裡的 where 加條件？
update xxx set xxxx WHERE pids = $prid
然後根據影響條數來判斷操作成功失敗？

另外 LS 說到打印的問題。
其實沒那麼複雜吧。
每次保存後記錄本次新增內容，
頁面生成的時候根據每次新增的內容用不同 DIV 包裹著，點擊打印的時候讓用戶選擇打印哪些內容，不需要打印的用 visibility 來佔位隱藏，配合 jqprint 就可以了。
不過實際上還會有些問題，例如用戶是修改了上次的內容，那那種辦法都不實際。
而且我覺得這個問題有點杠，不是不可能實現，而是沒必要實現。日常使用中，就算反面打印（手工）都會出現放錯紙，何況現在要增量打印？而且紙張價格不貴吧.......別扯環保問題，環保問題是有錢人才談論的。

換成 PDO，參數綁定下，SQL 注入問題解決。
XSS 注入的問題，過濾下，可以用 HTMLPurifier 來過濾，千萬不要只是在前端進行過濾。
權限控制，沒什麼好說的。進行修改刪除添加的時候判斷下資源是否屬於當前用戶。

赞成 11L +1
提提几个问题：
1、输入内容未进行过滤。
创建主题时候，直接输入 JS 代码就能直接 XSS 注入了。(我输入了个</script>window.location.href="http://www.v2ex.com";</script>，現在訪問跳轉來 V2EX 了。

2、權限控制沒做好。
通過 POSTMAN，直接修改參數提交到 admin/api.php 就可以了。哪怕不是自己創建的。

3、存在 SQL 注入點-

@passerbytiny 不是很认同这个说法。

首先前端如何都是要处理的，无非是怎么处理罢了(试问前端不处理，后端如何处理前端的事？
“删除，查询当前页数据，然后返回” <---基本分前後端后都是接口调用取数据吧？后端没必要在删除操作后再执行一次查询数据吧？后端直接提供->新增、修改、删除、读取四个接口，如果前端删除完，直接调用讀取 即可了吧？

题主的要求是
http://aaa.com:8443 -> https://aaa.com:8443
！（注意看端口号）

楼上的大哥，请问同域名同端口 nginx 是怎样区分服务？

那个，好奇问问，删除操作后前端不会重新加载列表吗？
后端必须有总分页数，
当前端提交的当前页数>总分页数，就直接把当前页数设置为总分页数。

写入 TXT 是不是有点多余？如果是必须写入的，那写入 MYSQL 和 txt 应该是同时进行，
基础数据有了做筛选时候通过 mysql 查询出来就行了。

@bestkayle @zaqzaq0125
你不說我都沒注意，不過你可以試試用搜狗輸入法，選擇繁體后 輸入個 yun，他出來第一個就是“云”。


@xunmima 见仁见智吧，老实说服务器的使用至今没出现过任何问题，只是感觉他在最不该翻车的地方翻车了心有不甘。

@bqx619 还好吧，我看了你那个帖子，你那里提的是需求，按我理解需求和故障回复时间应该不一样。而且老实说，回复你帖子的估计只是负责传话的某个客服，如果是故障他只能上报，影响大的可能加急。如果是需求或已知问题，估计他连上报的机会都没有，来来回回都是那套回复。

@Imr 我没吹嘘腾讯阿里，只是我三种都用过，阿里用的时间最短，因为他贵我穷，腾讯云除了 CDN 和 SDK 其他暂时没出过问题，价格不算贵，性能也不算最好。

@kimkcn
騰訊阿里我還沒試過這樣，不過我工單是 10 點左右提交吧，廣州區鏡像服務到現在還沒恢復，而且工單答復原因和電話答復原因不一致，重點是我覺得偶爾的故障是能接受的，但是有故障的時候 出下公告或者暫時禁用創建鏡像功能 實際結果會不會好一點呢？而不是用戶預計用 30 分鐘創建鏡像，然後創建鏡像時候發現時間異常長，然後又無法取消創建，只能通過工單等方法進行聯繫百度云取消，這樣一來一回預計的時間都超很多了

@X-Force CDN 我只用過騰訊的，不過騰訊的 CDN 要麼就是國內加速，要麼就是國際加速，兩者不能兼得。

@wxb2dyj @herozzm 沒太在意這些，且繁體簡體也沒什麼好裝吧，輸入法切換下就簡繁了，只是我自己懶罷了。沒那麼心大，反正都能看得懂。

@deepout 還是那句，真香定理，之前我也是拒絕的，後來看到價格后....嗯~真香

@ys0290 哈哈，我剛接觸的時候曾經試過寫了個雙語的程序，並不是刻意雙語切換，而是一個界面又簡體又繁體......
因為在公司里寫就是繁體，回到家繼續寫得就是簡體。

上面已經說啦...
公司港澳業務居多，所以電腦都是繁體字，
自己也懶得切換來切換去，所以在公司發帖都是用繁體字，
但是自己手機和家裡電腦就用簡體字。

@Telegram 我怕 open the door