[投稿隱藏表單]
名 稱
E-mail
標 題
內 文
附加圖檔[] []
類別標籤(請以 , 逗號分隔多個標籤)
刪除用密碼(刪除文章用。英數字8字元以內)
  • 可附加圖檔類型:GIF, JPG, PNG,瀏覽器才能正常附加圖檔
  • 附加圖檔最大上傳資料量為 512 KB。當回文時E-mail填入sage為不推文功能
  • 當檔案超過寬 250 像素、高 250 像素時會自動縮小尺寸顯示
  • 目前附加圖檔使用量大小: 25090 KB / 51200 KB
  • 程式碼可使用 [code][/code] 以 google-code-prettify 標亮 (程式自動判斷語言類別)
  • 本版因各種原因有鎖關鍵字,請至字詞黑名單一覽查詢。
  • 這裡是貼圖版程式 Pixmicat! 的相關使用問題回報討論版
  • 本版不是測試版!請自重勿隨意推舊文,謝謝合作

主題一覽
3504: ImageMagick安全漏洞 (0)3488: 無標題 (1)
3503: 適用於 8th.R4 的另類 mod_adminenhance? (0)3486: 請問架一個記憶體需要多少呢? (1)
3501: ADMIN刪除文章 (1)3484: MySQL 指令問題 (1)
3498: pixmicat 5 升級至 8 (1)3475: 有關升級 (6)
3497: pio 8.0 管理員密碼 (0)3473: 無標題 (1)
3496: Ninja (0)3470: 關於 Pixmicat網頁 (2)
3494: 關於錯誤訊息 (1)3468: 無標題 (3)
3493: 密碼錯誤 (1)3466: Pixmicat!-PIO 8th Release.4 (1)
3492: Pixmicat正式URL掛了? (0)3463: 美國知名程式碼代管網站GitHub (0)
3490: 有報錯但不影響運行 (1)3461: Pixmicat!-PIO 使用MySQL資料庫出現問題 (3)
無標題 名稱: taylorchu◆RXm61rnmYY [11/04/23(六)15:33 ID:2kNFvh4Y] No.3061 3推 [回應]
一般來說 外掛模組的掛載點 應該放置在那邊好呢?

老實說我製作的php apps已經完成plugin但是卻不知道優良掛載點位置
所以來問pixmicat如何決定掛載點的?
無名氏: See this → http://pixmicat.wikidot.com/pmcapi:pms (AZ4QOXs6 11/04/23 16:03)
taylorchu◆RXm61rnmYY: 我已經看過了 但是我比較想知道的是 "How do you design this?" (2kNFvh4Y 11/04/23 16:17)
◆ScRBg4WCkk: 關於這點你可以去參考具有模組設計的其他大型專案。我的做法是想到就加,要用就加,沒啥規劃。 (JAsOQxBA 11/04/24 11:43)

關於 archive 名稱: 無名氏 [11/03/26(六)04:31 ID:e7W6jzSw] No.3018  [回應]
請問有人有製作討論區 archive系統的經驗嗎?

因為pixmicat文章一被刷掉就不見了

常常有google的到,文章卻不見的情形

長期下來會流失許多潛在的訪客
無標題 名稱: Pichu [11/03/26(六)13:43 ID:h6m836x6] No.3021 1推  
類似的問題

AJAX對上SEO

雖然我覺得google很重要
但是假如為了google做archive系統 不知道好不好
taylorchu: 當然好 (JjCaKEec 11/03/26 15:44)
無標題 名稱: 無名氏 [11/03/26(六)15:35 ID:e7W6jzSw] No.3022 1推  
>>No.3021
為了google就是為了網站的成長....

google的重要性已經不是一般網站可以比較的了吧
taylorchu: pixc比較接近聊天室(設計上就是不容易保存資料) 你可以試試看 mod_archiver (JjCaKEec 11/03/26 15:56)
無標題 名稱: scribe◆ScRBg4WCkk [11/03/26(六)16:02 ID:YQ37Lkn.] No.3024   
傳統的futaba-style是沒有這種功能,一被回收刪掉就消失了。
因此我們有考量到未來的擴充性,在模組系統加上了 PostOnDeletion 這個掛載點,
可以讓模組來判斷需不需要對文章作個額外保存的處理。

不過目前是沒有任何模組有運用到這個點就是。
由於連精華區的生成格式都還沒有定見 (XML? MHT? HTM?),
因此也尚未製作此種模組。

舉個其他例子好了,就是因為目前沒有這種設計,
有些版就會把回收的上限調的非常的大,甚至不回收。
其實現在這個版也是使用這個方式。
無標題 名稱: 無名氏 [11/03/26(六)16:17 ID:e7W6jzSw] No.3026 2推  
>>No.3024
拿絕望版當例子好了...

現在絕望版是限制3000篇,全部有200多頁

因為每次發文都要更新這200多頁的快取,導致發文速度相當緩慢

如果在一些熱門版面的話就更恐怖了吧
◆ScRBg4WCkk: 有 STATIC_HTML_UNTIL http://pixmicat.wikidot.com/pmcuse:manage (YQ37Lkn. 11/03/26 16:25)
無名氏: 將靜態頁面的數量設低一點就好了呀 五頁差不多就夠了吧@@ (iYLoWUgU 11/03/26 16:26)
無標題 名稱: taylorchu [11/03/26(六)17:48 ID:JjCaKEec] No.3028 2推  
pixmicat為什麼會一次更新這麼多cache
如果是資料庫的話
每頁只要撈10筆post資料和相關的reply
照理說連快取都不用

我覺得像這樣更新
快取其實會加大負擔 有點本末倒置的感覺
◆ScRBg4WCkk: 因為讀比寫多。加上你可以選擇關閉。所以多overhead算值得啦, trade-off. (YQ37Lkn. 11/03/26 17:58)
taylorchu: 個人覺得只要有用到"分頁"就不適合靜態, 因為新增一個項目所有的內容都會向後一個單位,所有頁面都重做 (Gr0wpeVU 11/03/27 09:54)
無標題 名稱: 無名氏 [11/04/17(日)03:44 ID:yW08gOwE] No.3058 4推  
>>No.3024
有辦法把刪掉的串只保留HTML(刪掉發文表單)和縮圖

然後在?res=xxx的時候導向到該庫存頁面嗎?
◆ScRBg4WCkk: 這想法不錯,可惜res=xxx是完全由主程式控制,模組沒有辦法介入。你的需求只能直接去改主程式了。 (3yS5G./Y 11/04/17 10:47)
◆ScRBg4WCkk: 也就是在主程式發現無此討論串時,呼叫你自己寫的區段去找庫存 (3yS5G./Y 11/04/17 10:49)
ericpony: 建議可在 switch($mode) 前面增加一個掛載點, 讓模組決定要不要進入switch (Cg3nB8KY 11/04/20 07:24)
ericpony: 或是直接輸出ModulePage (必須限制最多只能有一個模組掛載此點). 如此可大幅增加擴充彈性. (Cg3nB8KY 11/04/20 07:30)

檔名:1283688523332.png-(55 KB, 1210x313) [以預覽圖顯示]
55 KB版面 CSS 修正提案 (針對IE) 名稱: scribe◆ScRBg4WCkk [10/09/05(日)20:08 ID:17B1A8bg] No.2767  [回應]
起源: No.2745 (http://2cat.twbbs.org/~scribe/pixmicat_dev/pixmicat.php?res=2741#r2745)

簡單來說目前的排版使用到 display: table 這個技巧在 IE8 終於支援了,但是卻無法選取其內文字。
這個情況在 IE9pre4 仍舊存在,看來他們打算不改了。
所以目前的版面,是把IE 8/9 都當成 IE7 來看,並且對它們用 Dirty divfix。

不過這不是件好事,我一直在找是否有其他替代方案全瀏覽器都通的,
最後還是覺得inline-block + float似乎還不錯,且IE6似乎也還可支援。(手上沒IE6了)

唯一的缺點,其實也不算缺點,是以往 futaba 的特色,第一篇回應可能會縮在內文下面的設計就沒辦法保留了 (見圖)。
我記得以前好像就有考慮用過inline-block + float,好像就是因為無法重現這個特色才沒改的樣子。

而使用這個的優點呢,當然是不必讓IE8/9再去當那個IE7了。
說實在的IE7改到一些地方反而跟Quirks/IE8不太一樣,是最難搞的瀏覽器。
大家可以試試IE8按F12的開發者工具,把文件模式改成Quirks/IE7/IE8看看,
你會發現發文框的那個拖拉小紅點竟然在IE7是爛掉的!?Quirks竟然還正確運作,
可見IE7一定改爛了什麼,IE8/9又改回來了。

至於現在的IE7使用者該怎麼辦?我只能說,不是升級到IE8/9嘛,就是用其他瀏覽器吧。
在成像引擎方面來說,IE6還比IE7還好搞一點。
無標題 名稱: scribe◆ScRBg4WCkk [10/09/05(日)20:12 ID:17B1A8bg] No.2768   
 檔名:1283688757623.png-(54 KB, 942x363) [以預覽圖顯示] 54 KB
圖是現在的情況。現在想想當初堅持這個幹嘛...

主要改動:
1. 刪掉iedivfix.js依賴,不需要Dirty divfix
2. display: table改用inline-block + float,兼具舊版本IE相容性和可複製文字

目前這個版就是套用修正的情況,看看IE各版本有沒有碰到什麼問題吧。
沒有的話,建議就用這個版本取代多年來用的Dirty divfix吧。
無標題 名稱: scribe◆ScRBg4WCkk [10/09/07(二)12:25 ID:ohRFlHBc] No.2769 2推  
 檔名:1283833532279.png-(14 KB, 884x518) [以預覽圖顯示] 14 KB
想起來了,當初不用的原因是因為圖中這個Bug。
IE8已經沒有這個問題,而IE6/7仍有。

看來得想點其他方案。

1. 尋求 display:table 下IE可複製文字的訣竅
2. 繼續尋求其他全瀏覽器通用替代方案
3. 維持現況,把IE8/9都當IE7
◆RTphpfqies: 換回<table>如何? XD (0/GwMBwU 10/09/09 14:07)
◆ScRBg4WCkk: 很爛的Solution XD (40xm34TQ 10/09/09 15:17)
無標題 名稱: Alica [11/04/13(三)15:42 ID:ZEjnUis2] No.3054   
無聊的解法就是多套一層<div style="display: table-cell">在div.reply裡面。這樣就可以幹掉iedivfix.js後開IE8/9標準模式了…本來想說用conditional comment+iedivfix.js給IE看時再動態插入就好,不過insertAdjacentHTML一定要插完整的HTML,不能一行插<div>一行插</div>(會XML syntax error);只好作罷寫死在樣板裡面。

各位可以用IE9(IE8沒支援application/xhtml+xml進不來)到螢幕攝看看情況。
無標題 名稱: Alica [11/04/16(六)12:47 ID:hnXlAo1g] No.3057 4推  
>>No.3054
已整理commit為r.810。主要修正三個樣板,目前規劃有支援display:table/table-cell的IE8/9都會使用標準模式解譯,原先的iedivfix.js仍保留供IE6/7使用。另外小幅修正樣板前端的快取控制指令,希望能增進快取效能。
◆ScRBg4WCkk: 因應這個結構變動,mod_pushpost也作小修正,可能還有其他也要改的 (LkiNih9Q 11/04/16 14:38)
◆ScRBg4WCkk: 不過2011/01/01剛好也是星期六喔?真巧。 (LkiNih9Q 11/04/16 14:38)
Alica: 無意間發現的w 上個一月一號星期一是2005… (OfmgFrl2 11/04/16 18:27)
Alica: 星期一/星期六 (OfmgFrl2 11/04/16 18:32)

thumb的檔案格式 名稱: Pichu [11/03/26(六)00:38 ID:h6m836x6] No.3015  [回應]
可以問一下嗎?

我個人認為就非自然(二次元)而言

PNG似乎比JPG更適合

不知道大家意見如何?
=========

會有這個問題存粹是看到thumb似乎都是輸出jpg
令我感到意外
無標題 名稱: scribe◆ScRBg4WCkk [11/03/26(六)00:50 ID:Nhz9cYbE] No.3016 1推  
我的意見嗎?WebP... (被拖走

不是啦,主要是預覽圖檔JPEG Quality可以調很低看起來也OK,輸出來的檔案也沒多大。
這種情形用失真壓縮反而是好的選擇。

我剛才隨便抓一張二次元圖縮到160x126。
PNG (c9+optipng+pngout): 24.9KB
JPQ (q0.5): 2.96KB
勝負立見,雖然PNG是比較清晰啦。不過JPG當預覽圖足夠了,因此也沒什麼意外的。
Pichu: 對吼 是預覽圖 真的是盲點.... WebP看來是個有趣的東西 (h6m836x6 11/03/26 01:29)
無標題 名稱: 無名氏 [11/03/26(六)15:43 ID:JjCaKEec] No.3023   
webp還至少有兩年的時間
其實效果和jpg差不了多少

png是和顏色單一(或不多)的圖片 像是logo
jpg則是適合照片(gradient)
無標題 名稱: Alica [11/04/12(二)21:44 ID:lavaXHbw] No.3053   
我對WebM/WebP沒啥信心,寧可挺ISO標準但就是起不來的JP2/JXR…不過其實重點還是要看最多人用的PHP內建GD支援到哪邊,不然其實改用ImageMagick轉縮圖的話pixmicat.php小改一點點就可以用WebP了。

自己補上.webp格式:
		switch($size[2]){ // 判斷上傳附加圖檔之格式
case 1 : $ext = ".gif"; break;
case 2 : $ext = ".jpg"; break;
case 3 : $ext = ".png"; break;
case 4 : $ext = ".swf"; break;
case 5 : $ext = ".psd"; break;
case 6 : $ext = ".bmp"; break;
case 13 : $ext = ".swf"; break;
default : $ext = ".xxx"; error(_T('regist_upload_notsupport'), $dest);
}


縮圖副檔名再指定一下:
		$thumbFile = $path.THUMB_DIR.$tim.'s.jpg'; // 預覽圖儲存位置
rename($dest, $destFile);
if(USE_THUMB !== 0){ // 生成預覽圖
$thumbType = USE_THUMB; if(USE_THUMB==1){ $thumbType = 'gd'; } // 與舊設定相容
require('./lib/thumb/thumb.'.$thumbType.'.php');
$thObj = new ThumbWrapper($destFile, $imgW, $imgH);
$thObj->setThumbnailConfig($W, $H, THUMB_Q);
$thObj->makeThumbnailtoFile($thumbFile);
@chmod($thumbFile, 0666);
unset($thObj);
}
無標題 名稱: scribe◆ScRBg4WCkk [11/04/14(四)00:12 ID:CkKUQcjw] No.3055 3推  
>>No.3053
根據未來支援格式而修改的程式已上傳SVN。

主要是未來的預覽圖檔包含但不限於 jpg,而又無從得知到底是什麼格式。
因此得先透過 $FileIO->resolveThumbName($tim) 得知完整包含副檔名的檔案名稱後,
再按照一般圖檔操作。

而 resolveThumbName() 同時也兼具 imageExists(預覽圖) 的功用,
因為如果找不到完整檔案名稱就代表沒有預覽圖。所以程式都改掉 imageExists(預覽圖) 的呼叫方式。

還沒有全面測,沒有自動化測試真難除錯。
如果我們有測試團隊的話,請努力測試並提出錯誤,謝謝。
無名氏: >如果我們有測試團隊的話 (nfHmGgvw 11/04/16 06:52)
Alica: bugzilla.mozilla.org/show_bug.cgi?id=600919 (jQQXC16E 11/04/21 11:20)
Alica: Firefox暫時不考慮支援ww (jQQXC16E 11/04/21 11:20)

檔名:1301320164824.png-(217 KB, 600x740) [以預覽圖顯示]
217 KB關於XSS 名稱: 無名氏 [11/03/28(一)21:49 ID:MOCol5Fw] No.3031  [回應]
請問pixmicat是怎麼防止XSS攻擊的呀?

謝謝(゚∀゚)
有回應 2 篇被省略。要閱讀所有回應請按下回應連結。
無標題 名稱: Pichu [11/03/29(二)16:05 ID:ch5VYn/E] No.3035 1推  
>>No.3034
XSS:
pixmicat.php
Line865~869
		$name = htmlspecialchars(str_cut(html_entity_decode(strip_tags($name)), 8));
$sub = htmlspecialchars(str_cut(html_entity_decode($sub), 8));
if($email) $name = "<a href=\"mailto:$email\">$name</a>";
$com = str_replace('<br />',' ',$com);
$com = htmlspecialchars(str_cut(html_entity_decode($com), 20));

CSRF的確沒有
只能仰賴版主定期更換欄位陷阱
假如是刪除文章型的CSRF 的確有被攻擊可能
但是也必須要有網友誤擊惡意連結
NUL byte injection我就真的沒聽過了
無名氏: $email? (jYwb43ak 11/03/29 23:51)
無標題 名稱: scribe◆ScRBg4WCkk [11/03/30(三)00:48 ID:oqbVlZbY] No.3036   
的確,XSS 已經成為網路安全不可忽略的一項防禦重點。
可惜 PMC 的確在這方面防範不力,只有作到最基本的HTML escape。

另外頻傳的綜合洗版,就可以知道CSRF根本沒有防。
其他的漏洞就更不用說了。

感謝大家的意見和重視,我們會努力加強這方面的防範。
無標題 名稱: Pichu [11/03/30(三)10:06 ID:3DjguRZw] No.3037 16推  
抱歉 CODE 似乎貼錯段了
	"'".mysql_real_escape_string($category, $this->con)."',". // 分類標籤
"'$tim', '$ext',". // 附加檔名
(int)$imgw.','.(int)$imgh.",'".$imgsize."',".(int)$tw.','.(int)$th.','. // 圖檔長寬及檔案大小;預覽圖長寬
"'".mysql_real_escape_string($pwd, $this->con)."',".
"'$now',". // 時間(含ID)字串
"'".mysql_real_escape_string($name, $this->con)."',".
"'".mysql_real_escape_string($email, $this->con)."',".
"'".mysql_real_escape_string($sub, $this->con)."',".
"'".mysql_real_escape_string($com, $this->con)."',".
"'".mysql_real_escape_string($host, $this->con)."', '".mysql_real_escape_string($status, $this->con)."')";

然後關於XSS 我認為最基本的HTML escape就夠了

CSRF的部分可以考慮用HTTP REFERER來防止

當然 這樣還是沒辦法防止惡意灌水的行為
((因為似乎可以說是比較熱於分享的使用者
只是大家不喜歡他的東西
……
無名氏: 可是curl好像也可以記session.......... (x85CAMaI 11/03/30 18:40)
無名氏: discuz的forum token都被破了 (x85CAMaI 11/03/30 18:40)
無名氏: form token (x85CAMaI 11/03/30 18:40)
Pichu: 一樓誤會了 我只的是無辜的孩子因為點了別人連結而造成的CSRF (jzPXVd8c 11/03/30 21:11)
Pichu: 基本上我只要寫個SHELL我就可以狂洗目前的pixmicat系統了 (jzPXVd8c 11/03/30 21:12)
Pichu: 但是IP都會是我自己的 所以要馬上鎖IP 事情就結束了 (jzPXVd8c 11/03/30 21:13)
Pichu: 但是假如別人誤擊連結 連到我的站 我就可以將Action導到其他站 (jzPXVd8c 11/03/30 21:14)
Pichu: 那麼發文IP將會是這位無辜的朋友 (jzPXVd8c 11/03/30 21:14)
無名氏: Proxy就可以解決鎖IP的問題... Proxy太容易找了 (x85CAMaI 11/03/30 22:13)
無名氏: 隨便都能找到幾千個 (x85CAMaI 11/03/30 22:14)
有部分推文被省略。要閱讀全部推文請按下回應連結。
無標題 名稱: RT◆RTphpfqies [11/03/30(三)10:24 ID:WFBYrk3I] No.3038   
>>No.3037
http://www.cgisecurity.com/csrf-faq.html

Can CSRF be prevented by implementing referrer checking?

No for two reasons.

First there are many ways that a Referer header can be blanked out or modified such as via web filtering software, parental control software, privacy software, proxies, or DOM trickery. This makes the referer header unreliable by nature.

Second Referer headers can be spoofed using XMLHTTP and by using flash as demonstrated by Amit Klein and rapid7. While these particular methods have been patched by the vendors, not every user visiting your website has applied these patches. Even if they did the first issue would still exist.
無標題 名稱: Pichu [11/03/30(三)21:22 ID:jzPXVd8c] No.3039 6推  
我記得CSRF當初提出來的攻擊是這樣的
http://foo.com/board?thread=13&method=delete
然後放成這樣
<img src='http://foo.com/board?thread=13&method=delete'/>


於是版主看到了這張圖 也刪掉了這篇文
因為權限機制是看session的
無名氏: @[email protected] 可是沒開bbcode的話, 附檔欄位根本不能自己設值不是嗎 (AXQjDkLw 11/03/31 00:00)
taylorchu: 這告訴我們不要把delete放進url (xuRK/9bM 11/03/31 09:37)
taylorchu: javascript也可以post csrf攻擊是相當多樣的 (xuRK/9bM 11/03/31 10:48)
Pichu: 所以不應該讓使用者有在自己站內放JS的機會 (rFZBtfm6 11/03/31 13:31)
Pichu: 然後我沒記錯的話XHR不能跨domain 然後我實驗結果普通的form可以跨domain (rFZBtfm6 11/03/31 13:32)
taylorchu: js是路人就可以 (xuRK/9bM 11/03/31 13:45)
mod_csrf_prevent 名稱: scribe◆ScRBg4WCkk [11/04/03(日)21:09 ID:O7qD6Pd6] No.3043   
mod_csrf_prevent
- Alpha版
- 僅檢查 HTTP_REFERER,雖然還不夠,總比沒有好

---

我記得我以前看過洗版程式,引誘他人到準備好的網頁,
網頁則是一個form,利用 JavaScript 自動送出以達到 CSRF。
最基本的看 HTTP_REFERER 可以阻絕這個攻擊,因為那個網頁表單並沒辦法偽造 HTTP_REFERER。

可是 Flash 的偽造就防不了。還有用 cURL 的那種也是。
如果作出 form token,我想 cURL 也可以先去抓 Token 值再來偽造送出,應該也能攻擊。
所以真的有心攻擊似乎擋不了,像 DDoS 一樣。

另外還有靜態怎麼放 Token 也是問題。
無標題 名稱: RT◆RTphpfqies [11/04/04(一)12:16 ID:ws9bXj5g] No.3044 1推  
>>No.3043
>另外還有靜態怎麼放 Token 也是問題。

>RT◆RTphpfqies: 發文確認頁或獨立發文/回文頁吧…但兩者也不討喜 (CSTgqLNA 11/03/30 18:30)
>RT◆RTphpfqies: 也許要用Javascript手段達成。 (CSTgqLNA 11/03/30 18:30)
無名氏: 發文確認頁不錯 然後把確認和取消放相反(減少錯字和回應錯 (1zf5TNQQ 11/04/12 15:17)
無標題 名稱: Pichu [11/04/04(一)12:58 ID:IyqSdmOE] No.3045 3推  
那假如是驗證碼呢?
Pichu: 或者是高負載或是疑似攻擊行為發生時啟動驗證碼 (IyqSdmOE 11/04/04 12:59)
◆ScRBg4WCkk: 有 JDownloader 可以把驗證碼圖直接抓過來再人工輸入的例子。所以說真要擋,擋不完啊。 (FvOPnR2M 11/04/04 14:09)
◆ScRBg4WCkk: 不過這已經變成不是在防CSRF,變成在防洗版了吧。就防洗版來說,自動開啟使用驗證碼好像還不錯。 (FvOPnR2M 11/04/04 14:10)
無標題 名稱: 無名氏 [11/04/04(一)23:58 ID:.SuG/A1I] No.3046 3推  
>>No.3045
>>自動開啟使用驗證碼
+1
facebook好像就是這樣防機器人的
只不過不知道怎麼判斷比較好
Pichu: 正常人使用的方式和惡意使用的方式我記得十分明顯 (gsT5K8bM 11/04/05 12:42)
Pichu: 不然就是先分出是廣告或是惡意灌水 (gsT5K8bM 11/04/05 12:49)
Pichu: 廣告的話可能就是關鍵字 惡意灌水就是抓異常的發文頻率 (gsT5K8bM 11/04/05 12:49)
請問... 名稱: 程式苦手QQ [11/04/10(日)17:38 ID:PiqZf1eU] No.3052 3推  
Pixmicat 的容量限制會自動刪除圖片
要如何連所屬文章也一併自動刪除呢
現在的情況是圖片消失了文章還在

不太懂php 這部份可以在config.php裡頭設定嗎??

感謝解惑QwQ
Alica: 反向思考,把文章數限小一些或圖檔容量限大一些就可迴避… (qUanJYDo 11/04/10 20:12)
◆ScRBg4WCkk: 拜託請不要回應在沒有關聯的文章裡面,下次看到就刪除。 (jRZZwVwA 11/04/11 00:19)
◆ScRBg4WCkk: 另外解答:不行,這不是改config就可以的,並沒有加入這樣的機制。要去修改原始碼 (jRZZwVwA 11/04/11 00:23)

pixmicat-gae - A Pixmicat! Google App Engine Clone 名稱: fshiori◆GquOB9lkXI [11/04/09(六)22:30 ID:5kOA1tuU] No.3048 2推 [回應]
Dears,
我目前正在研發一個基於Google App Engine的貼圖版
版面完全借鑑Pixmicat!但內容的程式完全以Python/App Engine重寫過, 目標是完成Pixmicat!的所有基本功能
現在完成的部份約20%, 基本的功能(發文/回文)大概可以Work吧=.=...

專案位置在
https://code.google.com/p/pixmicat-gae/
測試位置在
http://pixmicat-gae.appspot.com/

請各位先進不吝批評指教:)
無名氏: 加油!! (PiqZf1eU 11/04/10 17:28)
redwan: 加油!! (pNpRHn6A 11/05/02 14:42)
無標題 名稱: scribe◆ScRBg4WCkk [11/04/09(六)23:26 ID:dL8Kks5o] No.3049 2推  
你好。

我記得,你以前有貼過。我有印象,搜尋可能還找的到XD
很高興看到這個Clone,因為我對Python並不熟。

不過現在的GAE恐怕需要付錢才能撐住這服務了,
不是GAE撐不住(PaaS 雲端延展性不用擔心),是你的荷包撐不住XD
fshiori◆GquOB9lkXI: 其實這個專案我在Google Code開很久了, 只是之前一直沒有認真去寫=.=. (k02faxpk 11/04/10 00:00)
fshiori◆GquOB9lkXI: 怕之前的東西貼出來貽笑大方...所以我應該沒有宣傳過才對:) (k02faxpk 11/04/10 00:01)
無標題 名稱: fshiori◆GquOB9lkXI [11/04/10(日)00:05 ID:k02faxpk] No.3050 3推  
>>No.3049
GAE我認為在免費的額度內應該夠用了, 除了頻寬以外XD. 所以後端實作可能會參考PIO的方式, 將圖片存放到Google Storage之類的地方去
◆ScRBg4WCkk: 提到Google Storage我就氣啊,讓我終於等到了開發人員資格免費額度也沒了,要我拿錢測試?沒門 (P8PUSofs 11/04/10 10:20)
◆ScRBg4WCkk: 我不如去用比較便宜的Amazon S3,新申請還有免費額度。(不過我還是沒辦來測 XD) (P8PUSofs 11/04/10 10:21)
fshiori◆GquOB9lkXI: 現在才發現GS流量要算錢了~.~ 不過應該有方法可以克服 (fcmMdlks 11/04/10 11:19)
無標題 名稱: RT◆RTphpfqies [11/04/10(日)07:36 ID:0Jyc9s9w] No.3051 1推  
這個? XD
http://2cat.twbbs.org/%7Escribe/pixmicat_dev/pixmicat.php?res=2174
◆ScRBg4WCkk: 連結的時間點比較早,對比於專案的r1,看起來應該是不同人寫的...吧? (P8PUSofs 11/04/10 10:16)

【刪除文章】[]
刪除用密碼:
[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40]