有哪些讓你目瞪口呆的 bug?

問題描述:有哪些让你目瞪口呆的 bug?
, , , ,
徐曉軼:

看到上面誰說的光纖導致的一個故障,我也想起一個來:很久以前做一個基於波分復用的城域演示網,光傳輸用的是復旦的一個教授帶著群博士做的。

我搞定了IP側的路由器,放流量一跑都ok了,結果第二天一去,說斷了,我看了下是路由器的光口down了,重啟下就好了。第三天又斷了,靠,這咋活啊,我就把光口的技術參數給了那群博士,讓他們查查是不是兩邊的光功率不匹配啊。哦,一查還真是,他們做的是長途光通信,功率較大,還沒大太多,反正一天左右才把路由器的光口搞死。

然後一群博士開始討論該怎麼辦,都是光傳輸的東東,我也聽不懂啊,最後告訴我,要加個光衰減器,3000多,是刀還是軟妹幣的我沒聽清,主要是要等幾天。啊?!!這是中國工程師解決問題的套路嗎?!

所以,我拿過一個鉛筆把光纖繞了幾圈,用透明膠一貼,讓博士們再測下光功率,搞定啦:)


Aorqu用戶:

這是一個歷時5年,經過無數次排查才最終解決的BUG,而BUG的原因,卻又簡單到不可思議。

事情要追溯到2012年,我剛剛做程序猿不到1年,在公司做了一個網站程序,環境是小軟體公司常見的Windows+C#+SQLServer微軟組合,程序實現了什麼功能不重要,某天突然有客戶反映「登錄不上去,一直提示驗證碼錯誤。」這個驗證碼我做的是隨機取兩個0-9的數拼個算式,之後生成圖片讓用戶填答案(例如圖片生成內容是1+1=?,客戶要填2)。答案存在session里,用戶提交的時候就把填寫內容跟session裡面的答案比對。在確定客戶不可能一直做錯這種最初級算術題的前提下,開始了DEBUG。

然而我沒有想到的是,這個看似很小的BUG,卻如影隨形地跟隨了我5年。

1、初次交鋒

最初我在測試環境和正式環境下根據客戶敘述分別試驗,都未發現類似的BUG。嘗試遠程操作客戶電腦,問題重現,排除了客戶操作問題。嘗試重新獲取驗證碼、強制刷新、清除緩存等方法無效後。受到水準高超的網咖網管的最強解決方案(重啟、換機器)啟發,使用了【秘技:換個瀏覽器】,問題解決。

之後斷斷續續也有其他客戶反映同樣問題,也都通過此秘技恢復正常使用。但是這個奇怪的BUG原理卻完全不明白。使用同樣的功能,只有一部分用戶會產生這個問題,其他大部分人都是正常的。

2、獠牙初現

好景不長,換瀏覽器大法使用後沒多久,出現了第一批疑難雜症患者:問題又在新的瀏覽器上重現。

再繼續換瀏覽器終究不是辦法,通過各種手段也沒排查到問題原因,甚至連公司的一個測試人員也遇到了這個BUG。之前更換其他內核瀏覽器就好用可能是因為緩存問題,但之前刪除過緩存並沒有起效。我們抱著玄學的態度,清除了瀏覽器緩存,然後刷新頁面重新登錄——登錄成功。

原來IE這個功能其實清不幹凈。

於是我們的解決方案變成了【換成Chrome瀏覽器,如果還不行,就清緩存】

3、反擊

通過各種排查,最終確定BUG來源於session丟失,因為.net的session機制是本地cookies存儲了一個「ASP.NET_SessionId」,值與服務器上的sessionid對應,從而確定會話是來自哪台電腦。我當時猜測是因為本地cookies中的sessionid與服務器不對應,導致無法獲取會話資訊,所以session永遠是空的。而清除了cookies之後,重新為客戶端生成了新的sessionid,新的id有了對應後,問題解決。

因為在本地調試的用VS自帶的IIS Express不會出現這個問題,所以我認為這是服務器上IIS的BUG,但是網上檢索相關內容,無論是IIS的這個BUG,還是獲取不到session都沒有相關結果。

於是我心一橫,決定自己寫一套session,利用與iis類似的機制,通過客戶端cookies中的一個id來與服務端對應,這樣直接幹掉了IIS的session,就可以不用為這個BUG煩惱了。

編寫過程很順利,新的session通過測試,正式使用。上線後經過幾次細節修改,基本完美運行。

與session丟失BUG的戰斗也告一段落————本該是這樣的。

4、陰魂不散

樹欲靜而風不止,運行一段時間後,本應完全解決的BUG又捲土重來。與曾經一模一樣的情況,所有需要用到session的地方,都是返回空值。與曾經一模一樣的隨機用戶產生、難以復現。

反覆排查,卻一無所獲,這個BUG最大的難點在於我們內部很難復現這個問題,所以十分難以調試,而出現了問題的客戶,一般都沒法連接到對方電腦操作。只能通過不斷地猜測原因,然後修改代碼,祈禱這次的改動是有效的,這次的猜測是正確的。

經過了數次修改,效果卻並不理想。

5、柳暗花明

2017年的某天,正常工作中,在瀏覽器控制台中發現了一條異樣的cookie資訊

UserName=xxxx&Password=xxxx&copyright=xxxx

這條資訊是我設置的自動登錄,只要選擇自動登錄,便將賬號和加密後的密碼存儲到cookies中:

HttpCookie cookie = new HttpCookie("AutoLogin");
cookie.Expires = DateTime.Now.AddDays(14);
cookie.Values.Add("UserName", ul.UserName);
cookie.Values.Add("Password", ul.Password);
cookie.Values.Add("copyright", "公司名");
Response.Cookies.Add(cookie);

在控制台裡面,copyright是亂碼的,因為公司名字是中文,因為沒報錯所以就沒關注過。進一步排查,終於發現了5年前那個BUG的產生原理:

cookies是以文本形式存儲在硬盤里,而公司名字亂碼恰巧吞掉了字元串結束的限定符,從而使得這個字元串無限延伸,吞掉了後面的cookies。從而在framework獲取ASP.NET_SessionId的時候,取不到值,就產生了這個session黑洞。

至於為什麼部分用戶有這個問題,部分用戶沒有這個問題……因為大部分用戶ASP.NET_SessionId這條是在AutoLogin前面,不會被吞掉,而在後面的,都被吞掉了。

最後刪掉各項目中在cookies追加版權資訊的代碼後,問題解決,從此再也沒出現過session黑洞。

最終,一個困擾了我5年的BUG,竟然是這種令人哭笑不得的原因,而耗費了不少心血編寫和修改的自定義session組件,也因為經過幾年的時間,在各個項目中已經有了非常廣泛的應用,修改成本較高。再加上一直正常使用也沒出什麼問題,就繼續用了下去。


SPIREJ:

寫一個自己的

我是寫APP端的,封裝了一個view,因為好幾個地方用到類似的。

然後對接介面,因為介面不是一個人寫的,有一個後端發的字元串是這樣的 “¥1287.88″,而另一個發的是這樣的 “2221.23”。

我就想那我就自己判斷一下咯,有 “¥”開頭的就直接顯示,沒有”¥”開頭的那就拼接上顯示咯.

於是就寫了類似這樣的判斷:

if ([str hasPrefix:@"¥" ]) {
//...
}

但是…但是…不買我帳,沒走過這個判斷裡面的代碼塊~~~

於是就找啊找啊找啊找是哪裡出了問題呢!!!

打斷點呀,一步一步的執行呀,沒問題啊為啥就是不走判斷呢???

經過半天的尋找及冥思苦想,最後後端發的欄位里的 “¥” 和我寫的 “¥” 不一樣!!!

但是肯定看不出來哪裡不一樣!!!

後端發的 “¥” 其實是打拚音renminbi(人民幣)出來的符號”¥”

我寫的是 漢字拼音模式下 按住 shift + 4 出來的 符號 “¥”

這兩個其實是不一樣的東西~~~~QAQ 這么說你可能開始看不明白
上圖:

打拚音renminbi出來的符號

shift + 4 出來的符號

現在能看清楚了兩個符號不一樣,但是!!!在代碼里是看不出來的 因為他們會長得一樣 T.T


李明寬:
前幾天用12306官方客戶端買票的時候發現的…undefined趟列車(:з っ )っ


陳武賢:

可以刷紅包,可以直接將他人錢轉到自己賬號上算不?下文首發在公眾號《測試有話說》。

開發以為開發好了,測試以為測好了,然後錢還是被「合理」盜走了。

最近有各種拼手氣紅包小程序比較火,諸如包你答、包你拼、包你說等等。很多小程序都是匆匆上線,介面層面設計存在有很大的安全隱患問題,往往容易被人所利用刷紅包,刷提現等資金問題。用戶一旦發現資金被盜,那這個小程序基本是要廢了。

下面根據實際案例,給大家講講我是怎麼找到一個拼手氣紅包類小程序的漏洞的。當然,目的是為了學習,不是幹壞事。如果你是測試,那你可以在你自家產品上測試是否類似漏洞,如果你是開發,可以檢視下代碼避免出現有類似漏洞的介面設計。

下面是一個你畫我猜的小程序,發起方可以畫一幅畫,然後塞紅包,分享給好友猜,猜中的人就可以獲得拼手氣紅包。

↑↑好友通過分享進入↑↑

1、搶你紅包沒商量

第一步,抓包,通過抓包可以檢視進入圖畫頁所請求的介面返回數據:
https://api.*.cn/index.php/api/drawguess/wechat/Querygroupdrawinfo?t=1514290355&v=afabde532d9a8a4969663fc52870ad54&userid=U20171123062035992245&drawgroup_id=2418599&page=1

{
   "c": "0",
   "m": "",
   "d": {
   	"is_redpack": "0",
   	"ques_id": "997",
   	"draw_url": "https://..",
   	"img_url": "https://..",
   	"ques_user_id": "U201709171243335621796",
   	"draw_group_id": 2418599,
   	"prompt": "2\u4e2a\u5b57\uff0c\u4e50\u5668",
   	"ques_user_avatar": "https://..",
   	"ques_user_nickname": "\u854eKkkkkk",
   	"num_up": 0,
   	"num_down": 0,
   	"right_cot": 35,
   	"all_cot": 36,
   	"num_page": "1",
   	"num_reward": "0",
   	"is_sub_anwer": 0,
   	"anwer": "鋼琴",
   	"is_up": 0,
   	"is_down": 0,
   	"group_info": [{
   		"user_id": "U2017122611464418462",
   		"anwer": "\u731c\u5bf9\u4e86",
   		"avatar": "https://..",
   		"t": "20\u5206\u949f\u524d",
   		"nickname": "xuan \u00b7 dog",
   		"redpack_get": "0",
   		"redpack_money": "0",
   		"correct": "1"
   	}],
   	"redpack_money": "0",
   	"redpack_num": "0",
   	"redpack_num_send": "0",
   	"redpack_type": "0",
   	"rand_recommend": "3798417",
   	"act": "",
   	"pk_info": "",
   	"pk_id": ""
   }
} 

註:返回數據中的”group_info”值以及圖片地址是簡化處理過的。

從返回數據中結合頁面資訊,很多欄位都可以大概猜測是什麼意思,如:answer(答案)
,由於這個關鍵值的暴露,我們就可以輕而易舉知道畫裡面的答案,然後就可以做到無論畫了什麼亂七八糟的東西,我都可以回答正確,順利拿到紅包,如啥都沒畫我就猜中了:

這個時候,再深入研究下就會發現,介面請求參數中有個關鍵的欄位 drawgroupid(畫id),而且值是純數字,自己嘗試連續創作幾幅畫之後,發現這個欄位的值是按+1規律增長的,那豈不是可以任意回答任何一篇畫了?接著寫了個腳本循環就會得出下面的情況:

熱心的我把這個bug反饋給了開發者,開發者修復為:如果沒有回答對,介面返回資訊中的 answer 為空,所以你現在去試的話,會發現 answer 欄位介面資訊為空。

2、換個身份獲取答案

很多人以為上面的bug已經修復了,其實這個bug是沒有發現修乾淨的,怎麼說呢?大家再深入想下,這幅圖回答者不知道答案,總得有人是要有權限知道答案,在頁面顯示的吧?猜測是兩類可能可能有權要知道,一類是已經回答正確的回答者,一類是畫的創建者,顯然從畫的創建者權限入手找bug是比較合理的,畢竟一幅畫一定有創建者,但不一定有正確回答者。

我們重新回到介面返回資訊中尋找關鍵欄位,會發現有個 quesuserid ,可以斷定這個就是創建者的用戶id,抱著試一試的心理,我將請求介面中的userid的值更換為quesuser_id的值,結果發現,真的返回答案了。又可以繼續刷紅包了,表示很無奈呀。

https://api.*.cn/index.php/api/drawguess/wechat/Querygroupdrawinfo?t=1514290355&v=afabde532d9a8a4969663fc52870ad54&userid=U201709171243335621796&drawgroup_id=2418599&page=1

此時,再細細想一下,發現一個可怕的問題,這么說,這個小程序是完全沒有身份態一說呀,一個user_id走天下,所以接下來我又做了進一步的嘗試來證明我的想法,就是接下來要說的另外一個bug。

3、轉你錢沒商量

這個小程序跟錢相關的地方還有個贊賞功能,就是你欣賞一幅畫,可以對畫的創建者進行打賞,優先使用存在小程序上的餘額(免密)。這個時候我嘗試了一下查詢餘額介面,居然沒有做任何限制可以查詢,嘗試了贊賞介面發現只需要轉賬人id、接收者id、贊賞金額,三個關鍵參數就可以直接轉賬了,重點的是user_id也是有規律有序的,我嘗試遍歷了一下其他人賬戶餘額:

當然,我遍歷只是查詢餘額而已,沒有真正把其他賬號的錢轉到個人賬號上,畢竟這對這個小程序的生態破壞太厲害了,不是bug這么簡單了,我是通過把自己的贊賞其他用戶的形式來驗證自己的想法的:

事實證明,真的可以直接轉!!!非常熱心的我再次向開發者反饋這個問題之後,開發者默默的修復了這個問題,加上了身份態校驗,也就是請求參數中的 t、v 這兩個參數,其實這兩個參數一開始就有的,我也不知道為什麼一開始沒有生效,難道遺漏了?

總結

  • 身份態缺失:沒有身份態,直接使用user_id來進行判斷身份的實在是少見。其實小程序中,微信提供的token的很好用的一個東西,不知道為什麼很多開發者不願意使用。
  • 不該知道別知道:其實就是介面數據不要返回不該返回的資訊,一開始設計時介面設計沒有關心權限問題。例如上面大answer欄位,只要調用畫資訊介面就會返回所有資訊,導致回答者能直接知道答案。
  • 加密:與錢相關的介面最好是加密處理,雖然一樣可能被破解,還是可以起到一定的門檻作用的。

後話

提現、充值與前相關的介面設計也有一些常見的安全漏洞,下期關鍵字「並發」,關注《測試有話說》,下次再來說。

http://weixin.qq.com/r/qS-I0JzEP8FArdiz93q7 (二維碼自動識別)


Aorqu用戶:
真正的勇士 拿起代碼就是干 ( ・ิω・ิ)


益畝良田:

我是服氣的。


桃源君:

這也許也是一個讓人目瞪口呆的bug,比如2000多年前的「王莽新政」,新朝皇帝王莽頒布了一系列匪夷所思而又令人莫名熟悉的命令:

1,土地國有,平均分配:

王莽規定,人均土地一百畝,多佔土地的人家,不管是富豪巨室還是普通百姓,立刻要無條件交出土地,分給貧民,土地不許買賣抵押。而且土地重新洗牌,沒有土地的農民一對夫妻會分到一百畝田地,不足的由國家補償,這不就是另一個版本的土改?

2,廢除奴婢制度:

王莽當時十分痛恨奴隸制度,禁止買賣奴婢,買賣人口是「悖天心,逆人倫」的罪惡行徑,必須立刻停止。但是,真正禁止買賣奴婢也是在解放後才實現,看來王莽具有現代人那種人生來平等的光輝思想。

3,倡導勞動光榮:

王莽強迫無業遊民必須勞動,沒有具體工作的的遊民,每年必須罰布一塊,或者勞役,由國家承擔食宿。看來王莽蠻痛恨那些不勞而獲的行為。

4,實行計劃經濟:

王莽實行朝廷控制物價,禁止商人囤貨炒作,商人貨物低於朝廷定價隨意買賣,有點像今天的物價局。物價高於市平,司市官照市平出售;低於市平則聽民買賣;五穀布帛等生活必需品滯銷時,由司市官按本價收買。

5,實行專賣制度:

酒專賣,鹽專賣,鐵器專賣,由中央政府統一發行貨幣(從前任何富豪,都可製造銀錢,新政府收回這種授權)。山上水中的天然資源,都為國家所有,由政府開采。

6,建立稅收體系:

一切工商業,包括漁獵、卜卦、醫生、旅館,以及婦女們家庭養蠶織布,從前都自由經營,現在新政府都課征純利十分之一的所得稅。政府用這項收入作為貸款或平抑物價的資金。王莽在其稅制改革中,除了擴大工商業稅範圍徵收懶惰捐外,還提出「除其本,計其利,十一分之」徵稅原則,實為近代所得稅之先驅。

7,建立貸款制度:

人民因祭祀或喪葬的需要,可向政府貸款,不收利息。但為了經營農商事業而貸款,則政府收取純利十分之一的本息。

8,重視新技術和發明:

王莽當時做過很多實驗,但大多被儒家成為奇技淫巧的新生事物,並且還親手解剖人體;當時有人發明飛行器,王莽還接見那人並給錢資助,難道他知道科技對於生產力的決定作用?

9,實行廉租房政策:

王莽為消除貧困差距,在長安城中投資建設5個里共200個廉租房住宅小區,供貧民居住。

10,修改與周邊異族的關系:

王莽將匈奴單於改名為降奴服於…還將少數民族政權王降為侯;尤其是滅高句麗,並將其改名下句麗……(實在忍不住想吐槽一句,真是一個徹頭徹尾的民族主義者!)

這一系列改革是不是很眼熟? 此外還在教育、祭祀、法律、音樂、建築、歷法、度量衡、車輛製作等也有革新措施,簡直跨越時代啊,甚至還提出了『人人平等』的大同思想。

所以現在的廣大吃瓜民眾一致認為,這哥們兒肯定是時空穿越的BUG。

———————-分割線———————

關於王莽,還有很多超越時代的趣聞,比如:

1,漢哀帝掛了以後,王莽為了便於弄權,捧了一個小孩子登基,也就是漢平帝;第二年改元,這一年的年號是:元始元年。而這一年的西元紀年是:西元1年,東西方紀元就在這樣一個節點會合了。

元始八年(也就是西元八年,多吉利的年份,難道那個時候也流行八八八,發發發),王太後交出傳國玉璽,王莽正是登基,改國號為新,簡稱新朝。

2,王莽意圖統一全國的度量,發明了工具青銅卡尺,從原理、性能、用途看,這個「遊標卡尺」同現代的遊標卡尺十分相似,比西方早了1700年 。

3,王莽在世界鑄幣史上開創了主、輔幣相結合的「寶貨制」,他用一些做工精美但不足值的貨幣代替以前的金塊銀塊,簡直就是近代幣制改革的翻版。看看這個貨幣,像不像現代的鑰匙^_^!

4,還有種東西,也是王莽首創的,那就是短裙。

史籍記載,王莽的母親病了,公卿列侯都派夫人去探病,王莽的老婆出來迎接眾人。大家發現她穿著的衣服很短,下裝是布做的,長度只到膝蓋。大夥開始還以為她是僕人,一問才知道她是王莽的老婆,眾人都很震驚。

參考資料:

『《王莽,一個穿越來的皇帝》、《漢書》、《史記》』

關注桃源君,關注更多精彩趣聞:

1)桃源君——世界上有哪些著名的、失敗的大型工程項目?

2)桃源君——設計界有哪些最黑的黑科技?

3)桃源君——你見過哪些逆天的造假手段?


帆軟:

編譯器也有BUG!

找到編譯器的bug是種怎樣的體驗?

Quora上某大神經歷過的事!

原文大體是這樣:

「本人喜歡編程,上大學的時候,一直跟著學校一個很牛掰的老師做項目,是核心成員之一,而且我喜歡攻克那種高難度項目,在學校還算小有名氣。

那時候年輕,憑著一腔熱血沒日沒夜的碼,通常情況下一個項目需要幾天,熬上幾個夜才能完成。

有一天晚上,一個項目終於搞定,花了好幾天,然後交付測試,在測試框架中運行了幾遍,確保穩定。

當時我們的項目都是在學校的Unix系統上做的,所以我們用的是可共享的賬戶,提交項目的時候,只需要復制到助教可以訪問的只寫文件夾中。

提交後,我就回宿捨去睡覺了。

第二天早上,我手指發癢,早早醒過來,忙了一陣歇下來,突然覺得無事可做。

然後,我又的登錄並啟動了項目,然後還添加了一些其實很不必要的附加功能,純粹覺得有意思(好吧,就是想裝逼)。

大概弄了一個小時,搞定、編譯、測試。

突然之間,編譯失敗了大約30個地方,其中大部分都是沒見過的,然後我慌了,昨天晚上也沒發生這些錯誤,現在搞出這些幺蛾子,已經來不及了……

然後我開始調試,發現所有的錯誤基本上都是由於某些變量出現的無效數據,但是這些昨天晚上都已經確定好了,沒問題了,難道我搞錯了?

我首先刪除了我添加的所有新代碼,然並卵,還是很多報錯。然後,我嘗試用一個一個改這些變量,但我有幾十個地方使用過它,ORZ!

改了好久,簡直沒有盡頭。然後我走去食堂吃飯,路上一直反思和懷疑,是不是我昨天哪裡搞錯了,是不是有小夥伴動了我的東西,開始各種邪惡。算了,去找教授吧,重新做吧。

但冷靜之後,我理性思考了一下。是不是系統做了什麼而導致我的項目….而且在這個系統中,只要共享系統中的有更新,管理員就會在第一次登錄時在doc文件中發布資訊。

想到這,我立馬飛奔回去。果然,在一夜之間,管理員已將共享的gcc編譯器升級到新版本。

然後就是去質問,原來他們也發現了很多問題,正準備恢復變更。因為新升級的版本有一個bug,導致靜態成員初始化失敗。

整個下午,大家都在忙著把系統把項目恢復到更新之前。

整件事情特別有趣的是,我們都默認編譯器能夠使正確的,不可能出錯的,所以當我們遇到問題的時候,也只會在編譯器之外尋找原因。關於編譯器可能有錯誤的想法,以我當時的認知,是不可能想到的。

所以,這個BUG也算打開了我的視野,讓我對軟體工具本身有了不同的認知。當你編寫代碼和構建系統時,你會依賴於哪些東西,尤其是那些你甚至都沒有想過但是對你的成功至關重要的系統。你會天然相信他,但有時候,錯誤就在於此。

所以,要敢於批判。」


墨人自負:
說兩個人類大腦的吧。

第一個,人類迅速扭頭看時鍾,會覺得那一時刻的秒針停留的時間超過一秒。這是因為迅速移動的過程中,大腦來不及記錄下這么多視訊資訊,於是自行「腦補」了移動過程中的畫面。沒錯,是腦補,時間不能憑空少掉一點,便把這段時間都補上最先看到的秒針的畫面,於是秒針停留時間久了。所以,大多數情況下我們猛回頭的時候,根本不會在意這過程中看到了什麼。當然如果捕捉到了搶眼的正妹的話,當我沒說。

第二個,人類經常會覺得一些事情似曾相識,好像發生過。這是大腦調資料的時候發生錯亂,而拋出的異常。結果人類誤以為某事是彼時彼刻發生過的,其實可能是另一個時刻發生的,或者根本就還沒發生過。所以,以後不要老意淫那些「似曾相識相見恨晚」和「世間所有的相遇都是久別重逢」了~都是騙人的,錯覺而已。


Aorqu用戶:
一開始寫Python的時候,我特么哪知道Tab和Space有區別啊,unexpected indent 折騰我好久。


Aorqu用戶:


超然:

我來說一個…

單位福利給個月給沖五十塊錢移動話費,然後有一天移動小姐姐電話營銷過來,說移動每個月減免48,再算上單位50每個月,每個月98給我開個無限流量套餐。估摸著還行就同意開了。用了幾個月又感覺略浪費,就降到每個月18的最低套餐,然後開了個米粉卡。

然後驚奇的事情發生了…移動補貼的48不知道是因為後台偷懶還是咋地,48不是通過減免套餐的形式而是直接每個月定額充值48給我的。所以現在我用著18的套餐,移動還每個月給我48。

我估計我是唯一賺了移動回頭錢的人。


Aorqu用戶:
前情提要:
1. 最近我的WhatsApp經常受非法借貸的垃圾簡訊騷擾。
2. 我的WhatsApp開啟了兩步驗證,為了賬號安全,有時得輸入6位密碼才能進入WhatsApp。

前日,又收到一條,準備進入屏蔽(WhatsApp的屏蔽功能就不吐槽了)。打開WhatsApp,被告知要輸入兩步驗證的密碼。

我輸入了密碼。

WhatsApp沒解鎖,密碼卻被發給了那些垃圾簡訊的發送者。

非常想把WhatsApp的程序員拖出來大幾十大板。
(怒)ヽ(`゚Д´●)ノ ウルサイネン!!


董晶暉:
分享一個我在 GTA:San Andreas 遇見的最合理的 bug。
不知大家是否還記得如果你走進一家餐館,接著拔槍指向顧客,所有顧客和店員都會舉手起立,然後雙手抱頭蹲在角落。這是遊戲設計的搶劫系統。但是這個系統存在一個很有趣的bug。
因為餐館中的NPC正常狀態下都會吃東西。如果你把握好時機,在NPC剛剛把食物送進嘴的瞬間拔槍指向他,接下來:
他會昏厥並撲倒在餐桌上,並且再也不會醒來了。是的,他噎死了。
我不知道這究竟是個 bug 還是設計師故意隱藏的彩蛋,或者它只是為了掩飾一個動畫 bug 的偽彩蛋。但它是我在整個遊戲中見過的最棒的bug,即使其他諸如幽靈車、不死警察、高空變活人的bug 都無法相提並論。
因為,我可是達成了噎死成就的人啊。


centerocket:

剛剛我去有道詞典貴様(きさま)的讀音,

搜到了,然後發現還有語音。

然後我點了他的語音。

「%E3%81%8D%E3%81%95%E3%81%BE”,它說道。

讀作」percent E three percent eighty-one percent eight D percent E three……「

我就這樣在教室笑出了聲。。。


Doraemon:

不知道現在還有沒有人關注這個問題,這個問題我一定要答一發!

tuī tè(你們都知道這是啥)的驚天 bug,設置個生日或者改個生日就可能會導致賬號鎖死!

tuī tè 在 2018 年 5 月 25 日左右更新了使用條款,用戶必須要至少 13 周歲才能使用 tuī tè。

杯具在 2018 年 6 月 7 日這一天。我把我的個人資料里的生日改成了 2002 年 7 月 14 日(一個動漫人物的生日)。

然後出現了下面這一幕(這個截圖我一直保留著在)

翻譯一下:「要創建 tuī tè 賬號,您必須年滿 13 周歲。tuī tè 判定您不滿足年齡要求,所以您的賬號已被鎖定並從 tuī tè 中刪除。若您的賬號被誤封鎖,請點擊這里(一個鏈接)告知」

看到這樣的畫面,我首先是後悔不已,沒事手賤改什麼生日啊。但轉念一想,好像哪裡不對?今年是 2018 年,減去 2002,即使改了生日,我也有 16 歲啊,如果按周歲算,那也是 15 周歲啊,怎麼就低於 13 歲了?

但是先管不了那麼多,趕快提交投訴讓官方解開賬號再說。點擊那個鏈接,彈出來一個表格讓我填寫。(截圖里的郵箱不是我的真實郵箱,不用嘗試給我發郵件)

要填你的 tuī tè ID、你的郵箱、你的姓名,以及最關鍵的一條,上載能證明你身份的證件圖。我最開始腦子一熱,把身份證傳上去了。後來轉念一想,覺得還是上載護照更好點。然後我的郵箱收到了這樣的自動回復:

大意就是你還有尚在進行中的反饋,在前一條反饋解決之前請勿反覆發送其他的反饋。

沒辦法,先註冊一個新號湊合著再說。

再然後嘗試通過關鍵字搜索跟我一樣的受害者,發現每天都有成千上萬的受害者因為 tuī tè 新執行的「生日封鎖」(Birthday Ban)而丟失賬號。而且這條規則非常不可理喻,封號機器人的判定規則是【賬號創建時是否年滿 13 歲】,而不是【今年是否年滿 13 歲】

怪不得我的賬號會被封……我是 2012 年創建的賬號,雖然創建後直到 2017 年才開始投入使用,但是 2012-2002=10,<13。於是杯具了。

還有很多人比我還要慘得多,他們最早就一直填的自己的生日,從未更改過,然後 5 月 25 號新規則一生效,他們的賬號就突然沒了,只留下他們一臉懵逼。我不明白為什麼新規則要波及到在此規則建立之前創建賬號的人。還有就是,真的不滿 13 周歲就是罪不可赦的話,把 13 周歲前發的 tuī、點的贊刪了就好了,為什麼要大動干戈 BAN 了整個賬號。

還有一些企業號,將生日設置成了企業誕生的日子,然後因為他們的企業沒有成立滿 13 周年,他們的企業號就被封了。

在此次大面積賬號被封的風波下,tuī tè 的私信客服也癱瘓了。給客服發送私信,會自動回信說 Our Direct Message support is temporarily unavailable.

客服官 tuī 下面也是一片討伐聲。GIVE US OUR ACCOUNTS BACK! WE’RE NOT UNDER 13!!!

這條 tuī 也夠諷刺的了。「我們收到了比平常要多得多的投訴」,為什麼會變成這樣 tuī tè 你心裡真的沒點13數嗎!?

tuī tè 客服在 6 月 13 號那天發了一串 tuī 解釋為什麼這些賬號會被封,同時也承認了這是他們的錯誤。然而,直到目前為止(6 月 19 號),最新的 tuī 也還是停留在這一條上。沒有任何新消息。

tuī tè 上甚至誕生了一個話題,叫做 #StopTheBirthdayBans(請停止生日封鎖)。裡面各種各樣的控訴,甚至飆臟話。我以前一直不懂為什麼服務商提供服務了用戶還要反過來罵服務商。通過這次事情,我算是理解了。有些服務商,連一些基本服務都做不好,出問題了不是積極應對控制事態而是放任不管,是真的該罵!

最後,截止 6 月 19 日中午 11:45(UTC+8),我的原 tuī tè 號仍然處於被封狀態。我已等待將近兩周時間,仍未得到官方的郵件回復(估計官方的該系統已癱瘓,遂放任不管)目前仍然在耐心等待 tuī tè 官方解封中。

另外,這回答怎麼就 mǐn gǎn 了?


physixfan:

誰能告訴我這是什麼語言..?

這™可是一個銀行的網站啊,還是大名鼎鼎的花旗銀行啊…

發表迴響