Re: [閒聊] 檢證部騷動……

看板KanColle作者 (綾崎若菜家御用)時間9年前 (2016/06/05 14:28), 9年前編輯推噓24(25141)
留言67則, 23人參與, 最新討論串2/2 (看更多)
※ 引述《Romulus (Romulus)》之銘言: : 推 oscar1234562: http://i.imgur.com/9zJZgbL.png
所以這個無關? 06/05 14:18 : → comipa: 有用到twitter登入key的是Kancolledb,應該沒事 06/05 14:19 : 推 lonelyboy616: 想問艦colle db plugin的安裝流程 06/05 14:20 : → comipa: http://kcvdb.jp/KanColleViewer 這才是驗證部DB的plugin 06/05 14:20 : 推 ginmokusei: 樓上上是航海日誌擴張版? 06/05 14:20 : → lonelyboy616: 我是KCV 06/05 14:20 : → comipa: kancolle db如果你用本家直接改KCV的版本是不用裝plugin的 06/05 14:21 : 推 oscar1234562: 我的是擴張版日誌 06/05 14:21 : → lonelyboy616: 什麼意思? 是只要裝KCV就會直接傳資料過去的意思? 06/05 14:22 : → comipa: 擴張版日誌原生支援kancolledb,應該ok 06/05 14:22 太亂了..XD 總之我先假設 http://kancolle-db.net/ 跟驗證部沒有直接關連, 那現在雖然驗證部出事了. 我還是假設http://kancolle-db.net/沒事. 簡單來說原生支援http://kancolle-db.net/的版本大概有 http://kancolle-db.net/自己去merge KCV的版本: source code在這: https://github.com/about518/KanColleViewer/tree/send-database 版上也有大大會在KCV改版時去把db功能合進新版本. 以及 航海日誌(http://kancolle.sanaechan.net/)拡張版 還有KC3. 共通點就是你得用twitter登入弄個key給他. 所以需要key才會上傳. 驗證部的是這個: http://kcvdb.jp/KanColleViewer 會擔心可以先砍掉. 這個不用key就會傳了 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.163.109.17 ※ 文章網址: https://www.ptt.cc/bbs/KanColle/M.1465108107.A.C9A.html ※ 編輯: comipa (1.163.109.17), 06/05/2016 14:29:48

06/05 14:31, , 1F
推釐清
06/05 14:31, 1F

06/05 14:31, , 2F
說真的這種狀況下DB也不會安全到哪去啦
06/05 14:31, 2F
至少kancolleDB有source code...看得出來他傳了啥 ※ 編輯: comipa (1.163.109.17), 06/05/2016 14:32:36

06/05 14:33, , 3F
所以source code就直接載下來放到KCV的資料夾中就好
06/05 14:33, 3F

06/05 14:33, , 4F
是這個意思嗎?
06/05 14:33, 4F
當然不是, 原始碼要compile過. 會怕就先用最乾淨的KCV本家就對了,完全沒有上傳kancolledb功能 ※ 編輯: comipa (1.163.109.17), 06/05/2016 14:35:23

06/05 14:34, , 5F
看來就是抓原始的什麼都不用動
06/05 14:34, 5F
會怕這是正解. 因為kancolleDB提供的KCV修改版比較慢,所以我是自己有抓原始碼合過db版來build, 看原始碼覺得應該沒啥問題.. 但是我還是要免責聲明..出事不干我的事啊XD ※ 編輯: comipa (1.163.109.17), 06/05/2016 14:37:47

06/05 14:37, , 6F
算了 之前都還在用4.2.4 乾脆砍掉重裝4.2.5好了
06/05 14:37, 6F

06/05 14:38, , 7F
感覺比較省事
06/05 14:38, 7F
會擔心請用KCV本家無誤. ※ 編輯: comipa (1.163.109.17), 06/05/2016 14:41:48

06/05 14:42, , 8F
還好我是用poi
06/05 14:42, 8F

06/05 15:15, , 9F
用poi+1
06/05 15:15, 9F

06/05 15:32, , 10F
所以4.24的KCV有類似功能嗎?!去哪裡弄掉?
06/05 15:32, 10F

06/05 15:34, , 11F
剛剛喵了一下我的 yuubari版4.2.4 看起來也是沒有DB
06/05 15:34, 11F

06/05 15:34, , 12F
有錯幫忙指正一下XD
06/05 15:34, 12F

06/05 16:02, , 13F
kancolle db沒事也中槍XD
06/05 16:02, 13F

06/05 16:11, , 14F
poi不是也會上傳資料嗎?這樣也沒比較安全吧
06/05 16:11, 14F

06/05 16:23, , 15F
一直都只用原始版本日誌..
06/05 16:23, 15F


06/05 17:12, , 17F
這個是本家沒有修改過的嗎?
06/05 17:12, 17F

06/05 17:14, , 18F
yes
06/05 17:14, 18F

06/05 17:18, , 19F
多謝
06/05 17:18, 19F

06/05 17:22, , 20F
這次真的Kancolle-db躺著中槍
06/05 17:22, 20F

06/05 17:22, , 21F
因為都是DB來DB去的 一開始看根本不知道在說的其實
06/05 17:22, 21F

06/05 17:23, , 22F
是另外一個檢證群自己另外做的DB
06/05 17:23, 22F

06/05 18:06, , 23F
這次最糟糕的是其他驗證勢風評被害
06/05 18:06, 23F
真的,牽拖到其他有心經營的就傷腦筋了.. 說真的像這樣造成誤解大家都不願意上傳資料的話. 以後連撈船想找個機率高一點的地點都會很麻煩.. ※ 編輯: comipa (1.163.109.17), 06/05/2016 18:19:57

06/05 21:20, , 24F
這假設不成立,結束
06/05 21:20, 24F

06/05 21:21, , 25F
DB已經完全是檢證部漱@部份
06/05 21:21, 25F

06/05 21:24, , 26F
並不是什麼另外的DB
06/05 21:24, 26F

06/05 21:24, , 27F
在爭的資料也就是這個DB 根本沒有躺著而是在跳來跳去
06/05 21:24, 27F

06/05 21:26, , 28F
之前U和401的掉落率調查也就是這個DB
06/05 21:26, 28F

06/05 21:40, , 29F
.....所以結果就是啥DB傳送都別用就對了?
06/05 21:40, 29F

06/05 21:50, , 30F
日製的大部分都是送給DB 全部不要送 poi不用改
06/05 21:50, 30F

06/05 21:52, , 31F
日誌那個就是設定>通信>最下面那個選項別勾這樣(?)
06/05 21:52, 31F

06/05 22:07, , 32F
比想像中更嚴重阿...還以為是不同世界的事情
06/05 22:07, 32F

06/05 22:08, , 33F
不要在意資料外洩,而是要享受那個過程
06/05 22:08, 33F

06/05 22:26, , 34F
強X 換成這樣也可以XD
06/05 22:26, 34F

06/05 22:32, , 35F
啥,兩個DB同一個喔...那我沒搞清楚就講真是太白爛了
06/05 22:32, 35F

06/05 22:32, , 36F
非常抱歉...
06/05 22:32, 36F

06/05 22:40, , 37F
me 2..... Orz
06/05 22:40, 37F

06/06 00:18, , 39F
這是我之前把KCV-DB抽出來改plugin的code
06/06 00:18, 39F

06/06 00:18, , 40F
https://goo.gl/1coq2H 會傳送的網址有這些
06/06 00:18, 40F

06/06 00:19, , 41F
還沒仔細了解過這次狀況,傳送這些資料有危險性嗎?
06/06 00:19, 41F

06/06 09:06, , 42F
poi預設没送東西...
06/06 09:06, 42F

06/06 09:25, , 43F
最基本最基本 DMM拿到這資料就可以當證據把你給BAN了
06/06 09:25, 43F

06/06 09:25, , 44F
使用外部工具
06/06 09:25, 44F

06/06 15:14, , 45F
這次事件後讓我不敢再傳資料給任何DB了.....
06/06 15:14, 45F

06/06 16:41, , 46F
想傳又怕受傷害的話 可以去研究看看統計DB到底收那些
06/06 16:41, 46F

06/06 16:41, , 47F
資料
06/06 16:41, 47F

06/07 00:35, , 48F
瞭解...那還是啥都別送好了...
06/07 00:35, 48F

06/07 09:37, , 49F
啊非常抱歉我重新調查以後發現我搞錯了
06/07 09:37, 49F

06/07 09:37, , 50F
統計DB和驗證DB是不同的東西
06/07 09:37, 50F

06/07 09:38, , 51F
只是統計DB管理人有在檢證部裡面而已
06/07 09:38, 51F

06/07 09:38, , 52F
可是統計DB我現在也沒啥信任度
06/07 09:38, 52F

06/07 11:07, , 53F
基本上就是Romulus說的那樣 資料應該是分開的
06/07 11:07, 53F

06/07 11:07, , 54F
plugin也是不同的 但是人員同樣是檢証部的
06/07 11:07, 54F

06/07 11:08, , 55F
如果想放心的話 至少統計DB的人沒在這次的抓馬裡出現
06/07 11:08, 55F

06/07 11:08, , 56F
管理
06/07 11:08, 56F

06/08 06:40, , 57F
只能說poi跟db.net沒事也中槍~74式在這次事件之後應
06/08 06:40, 57F

06/08 06:40, , 58F
該會把分送到検証DB.jp的砍掉吧。 個人看了看,這根本
06/08 06:40, 58F

06/08 06:41, , 59F
是KC官方底下的部門自己在跟高層吵架,結果自爆有在收
06/08 06:41, 59F

06/08 06:41, , 60F
集玩家的課金資料。 至於非KC官方的db(poi、db.net),
06/08 06:41, 60F

06/08 06:41, , 61F
目前是沒問題的。
06/08 06:41, 61F

06/08 17:24, , 62F
KC官方?????????
06/08 17:24, 62F

06/08 19:50, , 63F
他應該是說這次出問題的檢證部跟官方營運應該有直接的同僚
06/08 19:50, 63F

06/08 19:51, , 64F
關係,不過這不是很肯定舊式
06/08 19:51, 64F

06/09 12:58, , 65F
不是這個意思 檢證部跟官方營運沒有任何正式關係
06/09 12:58, 65F

06/09 12:58, , 66F
是檢證部中有人在官方那邊有消息來源
06/09 12:58, 66F

06/09 12:59, , 67F
但是也不是正式渠道 更像是口耳相傳的小道消息
06/09 12:59, 67F
文章代碼(AID): #1NKyQBoQ (KanColle)
討論串 (同標題文章)
文章代碼(AID): #1NKyQBoQ (KanColle)