JSON 是不支持 comment、运算符等等的，你所使用的是 JavaScript 对象
如果你用你把你刚才 object 转换成字符串，再用 JSON.parse 解析会解析不了的。
請問 PJSON 是不是也是 JS 對象？
PJSON.parse(PJSON.stringify({
/*asdfasdf*/

a:1
}));

請問結果是什麼？


另外你说的 ajax 提交是不能直接提交 JavaScript Object 的，他需要使用 JSON.stringify 转换成字符串才能通过 GET、POST 请求发送，而你刚才的那些代码是没办法转换成 json 字符串的

var a = {
// cmd 123123
helloText:'abcdefg',
mlText:"asdf\nasdf",
/*testtest*/
abc:123,
tst:1*2*3*4
};
var b= JSON.parse(a);

ajax 提交這個 b 可以了吧？
但是 PJSON 是可以簡化哪一步呢？

還有各種語言對 JSON 的支持和支持庫你也可以上 json.org 看看。
如果換成 PJSON,請問支持庫是有...？


最後一問，
文檔中說 PJSON 最厲害是加入了運算支持，
請問可以把 JS 的計算精度問題修復下嗎？

PJSON.stringify({a:0.1+0.1+0.1});
"{"a":0.30000000000000004}"

我再 chrome 的 console 試了下：
console.log({
// cmd 123123
helloText:'abcdefg',
mlText:"asdf\nasdf",
/*testtest*/
abc:123,
tst:1*2*3*4
});

返回：
abc: 123
helloText: "abcdefg"
mlText: "asdf↵asdf"
tst: 24
__proto__: Object


請問為什麼需要用 PJSON ?

我直接用 JSON 他不香哦
----------------------------------
然後看到你說的數據交換，
也看了你的文檔和說明，
但未找到具體怎麼轉換。
所以想問問你交換的時候他是怎麼交換？




另外，最實際的一個問題，

在 JS 裡，我 var a={xxx:123}就是 JSON 對象了，直接 ajax 就提交去後端了，
在 php 裡我使用 json_encode(array);就能輸出 JSON 對象，JS 直接就能使用了，
在 C#裡我引用個 fastJson 就可以了。

請問如果替換成 PJSON，對我而言是簡化了哪裡呢？

@ADME 老實說，缺的不是那幾塊錢，而是一口氣。
如果你常熬夜，
深夜時候你並不會在意能優惠多少錢，
而在意的是睡前的溫飽。
如果真的運力問題接不了單肯定生氣，但自己也是人，也能理解到苦衷，
可是直接把賠付取消掉了，這我就真的不能理解了。

@chent 並不是沒什麼，我覺得這個最起碼是企業信譽問題吧。
我在美團外賣月消費 1.3k~1.5k ，大概一個月賠付可能有 30 左右。
但餓了麼的系統取消訂單真的很惡心，其實點超時並不是為了那幾塊錢的賠付，只是想能相對的盡快送到。
凌晨兩點點外賣，（別說我極端，你平台可以禁止這個時間段點啊，商家也可以不接啊）
平台收錢了，商家接單了，配送時間 45 分鐘我也接受了，
誰知道你 TM 超時後才說系統取消訂單，
賠付金額直接為 0，
我白等了 65 分鐘，最後餓著肚子睡。
餓了就叫餓了麼？我 TM 是餓死了你都不來收尸！

投訴沒用，試過幾單是這樣的了，
點了餐，買了超時。
我凌晨 2 點下的單，
提示 45 分鐘送達，
到 25 分時候發短信運力緊張，將進行調度，有可能延遲。
超時 20 分鐘，短信提示訂單被系統取消。
試過幾次，都是系統取消的訂單，都是買了超時賠付，最後一分錢都沒賠付的。
然後會員取消了，以後都沒使用過餓了麼，
哪怕餓了麼某些我想點的比 XX 便宜。

@LuLucius 不是黑客，更別扯什麼老大了。
黑客是在找一堆漏洞，默默的拿起筆記本抄下，等用的人多再拿出來賣。

不過可以給你個建議啊，你做個類 SaaS 系統，
客戶選完後直接把域名 cname 過來就可以了。（這裡可以選擇和雲廠商合作，你們抽佣金。

另外提供個定制界面服務，開放給第三方的開發者接單。（你們也可以抽佣，然後做個評價系統，開發者弄完後客戶評價，評價高的開發者排前面。

還有現在公安等保又要求做等保評級，你可以整個系統進行評級，然後客戶就複用你們的資質即可。

最後就是提供私有化部署服務，客戶對資料信息敏感的就購買此項服務即可。

但是目前還是建議把已有的功能先完善好了，確定好客戶群體和目標，再去想其他的東西了。
畢竟一開始花心思在如何賺錢的地方肯定做不好產品。產品做好了只要動動心思處處都能賺錢。

@lufeng08 給個 XSS 注入點給你。
/forum/post/index?id=100044

@lufeng08 其實我只是站在顧客角度去想，技術跑去做業務最大的難度就是在於無法換位思考。有些東西在技術層面是理所當然，但是業務市場卻並非如此。
真有心做的話你可以調查下現在做最多的系統 /網頁需要用到哪些模塊，在對比下同類型系統他們的價格，
然後把相關功能給第三方科技公司報下價，你們對比下這些價格。
另外還要考慮下你們客戶群體是什麼人，根據定下來的客戶群體做針對性的優化，推廣也是針對這堆人做。
做好了這堆人再尋找次要的群體去做一步步走大，針對性太多反而很難做出自己的特點。
反正不是燒錢推，一兩年內別想著有回報。

看了下，你們是做了個系統，賣功能模塊賺錢。
這套模式很早就有人玩了，而且你對比下別人現有的模塊功能價格，我覺得你們這裡應該沒有優勢。
二維碼：99 元、消息中心：198 元.....是不是偏高？
另外看了下示例，好像都是千篇一律的排版樣式吧？
如果要做個商城，大概價格是：
第三方登錄 998+工單 998+消息 198.00+支付 998+幫助 498+積分 998，合計就是 4688，然後服務器域名等都要自己租，租完還要配置。 而且以上這些功能因為是模塊化，樣式變更估計自由度不大，而且就算開放 CSS 讓顧客修改，也要顧客會修改才行。

如果你這套系統針對的是有技術團隊的公司，對方為什麼不自己開發出來呢？
如果你這套系統針對的是沒技術團隊的公司，對方怎麼改樣式？
那麼你這套系統只能針對有一點技術的公司，對方為什麼不選擇上線更久功能更多的其他系統呢？


老實說我沒親身體驗過，以上的言論只是大致看了下說的，不存在言語攻擊性，不喜勿噴。
對了，現在一般科技公司幫客戶定制一個以上功能的系統，價格大概 6000~8000，可是人家是定制的，而且包服務器域名一年費用，顧客只需要給錢給意見就行了，而不是自己跑上去搗鼓一通。

不用想，只要算。
自己上行带宽和对方下行带宽，计算下大概时间。
如果和快递时间差不多就快递吧，如果比快递时间少就直传

通白点解释就是
两个狼友去按摩，
小明点了个 QT
小强点了个 Kb

老板分配手牌给小明，编号 12
分配手牌给小强，编号 55

然后他们各自进房，小强看到有 JS 经过时候，马上拉她进去，说我手牌是 12，
此时 JS 拿起房间电话打去前台说 12 上钟，前台看到有 12 这个编号，就回复他要做 QT，然后挂了。

小强做完一些嘿嘿嘿的事情后，拿出手牌根据 KB 的价格买单走人了

header:
Cookie:PHPSESSID=dcfab8f112bb806089dba16dbb109362


POST:XXXX/admin/api.php

body:
pid:6
act:delete_project
prid:32

response:
{"status":"SUCC","msg":"\u64cd\u4f5c\u6210\u529f!"}

@rustkeyboard 已刪

或者我說白點吧，
$pids -> 是 session 中的，我沒理解應為 project_ids 即項目 ID 的意思吧，
添加文章後，數據庫保存了添加的 ID，還有項目的 id(prid) 沒錯吧？
然後修改的時候，通過判斷 提交的 prid 是否包含在 session 中的 pids ,如果包含在裡面的話就執行更新；這裡沒錯吧？
那麼你自己也說，prid 是可以伪造的，既然判斷條件是可以伪造，那你怎麼保證判斷的結果不是伪造的結果呢？
假設：
session 中的 pids=32
我直接提交伪造 prid = 32
那這個判斷就已經過去了吧？
然後直接就執行了 undate 或 delete 了。

@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 就可以了。
不過實際上還會有些問題，例如用戶是修改了上次的內容，那那種辦法都不實際。
而且我覺得這個問題有點杠，不是不可能實現，而是沒必要實現。日常使用中，就算反面打印（手工）都會出現放錯紙，何況現在要增量打印？而且紙張價格不貴吧.......別扯環保問題，環保問題是有錢人才談論的。