V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  markgor  ›  全部回复第 33 页 / 共 46 页
回复总数  908
1 ... 29  30  31  32  33  34  35  36  37  38 ... 46  
2021-01-03 13:20:22 +08:00
回复了 vicence 创建的主题 浏览器 浏览器请求中还有其他 IP 地址的请求问题
@vicence 不通......
幫你组织下语言吧,
用户请求处于服务器 A 的一个网页,
可是网页中包含服务器 B 的资源,
而服务器 B 和用户所在的网络事隔离开的,
请问用户能正常加载服务器 B 的资源吗?
2021-01-03 09:19:42 +08:00
回复了 WishMeLz 创建的主题 职场话题 我又来吐槽公司了,这次老板发飙了
1 、节假日期间,用户量大的话肯定安排 1~2 个留守值班,人不够的情况下各退一步远程值班。值班并非为了处理问题,而是记录问题,及时反馈。
2 、如果公司没这项安排,恰好我自己又是该项目负责人的话;看到了,不回复,我职业道德问题。没看到,迟回复,别进行道德绑架。

看了 LS 的回复,我没看过 LZ 之前得帖,不清楚前因后果,但反正什么原因,我觉得开发最重要的还是责任心。互换角度,其实都不容易,2020 考验的是中小企业老板抗压能力。
其实拖报销稳资金流的看法我不同意,
一个公司的资金流不可能因为被报销给左右吧?
除非全都是垫资货款....但如果需要垫资货款,那问题就不是报销慢了吧....

我们这报销流程比较简单,
发票 /收据,发申请,部门主管同意就到经理审批。
经理审批后会实时垫资给员工
整个流程 3 天内完成。

但财务那边计算 1~2 个月才会拨款下来个经理....
2020-12-29 17:22:36 +08:00
回复了 zealinux 创建的主题 程序员 莫名的接口访问,不知道该怎么防?
挂代理扫漏洞的...
同 IP 访问频繁的直接 ban 了就好了...
我上次就是这样不小心 ban 了个 CDN 节点....
后来..............
2020-12-23 14:43:12 +08:00
回复了 CloudStorage 创建的主题 推广 时代新宠儿——HEIF 图像格式:节省 50%空间
webp 到现在都没推广开来,
TPG 提供商业服务,但是针对 web 场景也无能为力。
HEIF.......
2020-01-22 11:01:52 +08:00
回复了 lysS 创建的主题 PHP mysqli_query 的操作为什么这么迷?? `和'的区别??
這個和 mysqli_query 沒多大關係吧...
mysql 欄位正常寫法就是``,
sqlserver[];

然後插入的字符 ''。
@binux

你知道 X-HTTP-Method-Override 这样的方案吗?<---確實之前不知道。
但剛看了,需要後端配合,當收到 X-HTTP-Method-Override 時候重寫 method。
但其實就是過了安防那一塊吧,waf 等不需要進行處理,nginx 等也不需要額外配置其他。
還有就是後端一開始如果是完完全全按 resetfull 設置的話也可以不用進行修改。

但是如果我援用 POST 來跑,除了優雅,性能上有多大的區別呢?

如果是新開發的應用,用什麼大家提前說好了我覺得問題不大。
但是修改現有系統,你覺得呢?除非我是老闆,否則我單以“優雅”二字要求後端和前端去修改,可能性不大吧。


“从小的地方,这里改一点,哪里推进一下。当真的要推一个重新设计的时候,你会发现这时就不这么难了。”
這句話,我以前一直都相信。
但是往往是,“这里改一点,哪里推进一下”,最後出 BUG 了,然後修復後整條業務線平靜下來,我得到的只是罵名。
(*說句題外話,曾經試過,幫別人修改一下 HTML 靜態文件,然後過了兩天,對方 oracle 掛了,對方運維排障,前 2 天有人改過東西。嗯沒錯,這鍋最後我背了,後面排查是因為 listen log 超 2G 的原因,但也不重要了,反正鍋已經牢牢扣我身上)
@binux 哈哈,又見面了,上次我記得也是在說 api 規範上面討論過。
首先我認同你所說的,我年輕時候也是這樣想,為什麼沒有人能打破陳舊?
但每次打破陳舊的背後背負的責任實在太重了,現在年近 30,雖然沒達到你說的 35,但我的思想已經接近了,以前留下來,沒有大問題,不做修改。

回到題主的問題中。
我不可能頂著壓力,跑去懟全世界,要求把 api 接口都按 resetFull 重新設計,然後說出一大堆冠冕堂皇的理由,但最終明眼人都能看出來,這小子為了“好看”,“跟風”所以要求改。
老實說,使用 PUT/PATH/DEL 來處理對應的業務,除了優雅外優點在哪裡?


對了,不是不願意學些,而是不願意在生產環境上學習。
我記得你說過你的業務基本是對接海外的產品,那麼我只能說國內環境不一樣。
就權當我能把運維前後端說服了,
大家都願意去對現有系統進行修改。
然後後端出現了一個新的問題。
此時此刻,後端心理肯定在罵我的,甚至還想甩鍋給我。
國內的環境你有時間可以看看阿里雲的前世。
我也覺得使用 POST/GET 比較好。
第一:常規請求就是使用 POST/GET 進行的,這兩個方式一般不會翻車。
第二:由於 PATCH/PUT/DEL 請求比較少眾,如果為了方便和通用性,還不如改為 POST/GET。
第三:WAF 一般都會攔截這些操作(當然可以手工開啟),另外自動化滲透也會爆“疑似配置不當”,如果是網警出函,則需要書面寫說明回復。(當時有個站點由於需要跨站操作,開啟了 OPTION,但是有配置 allow,最後還是一個月收一次函,第二次收函時候直接把 OPTION 關了,域名增加多了個解釋就好了..)..

使用 PATCH/PUT/DEL 這些
優點:在於遵守 resetfull 的建議,通過接口 method 就能大概知道做什麼的了。
缺點:上面的 1、2、3.

使用 POST/GET 這些
優點:上面的 1、2、3.
缺點:不夠 resetFull 優雅,需要從接口參數才能看出大概做什麼的。

但是,現在基本的 api 都有搭配文檔的,所以我覺得已經不需要從 method 來看出他是做什麼的,畢竟就算你能從 method 看出作用,最後還不是要乖乖地看文檔?
2019-12-30 12:28:39 +08:00
回复了 CallmeDredd 创建的主题 程序员 大家帮忙看看百度网盘的这个逻辑设计合不合理
@icris #32 結束 ≠ 完成
2019-12-29 18:12:12 +08:00
回复了 CallmeDredd 创建的主题 程序员 大家帮忙看看百度网盘的这个逻辑设计合不合理
@also24
好的,明白你意思了,是我誤解了。

不過我更傾向於 “我”打開的就由“我”關閉。
----------------------------
我過我覺得這個問題更像 確定按鈕在左邊還是右邊。
我個人感覺,國內的大部分左邊取消右邊確認。
國外的傾向於右邊確認左邊取消。
2019-12-29 17:56:44 +08:00
回复了 CallmeDredd 创建的主题 程序员 大家帮忙看看百度网盘的这个逻辑设计合不合理
@also24

菜單文字是“本次传输完成后自动关机”

我覺得沒有二義性吧?
語法上的二義性指的不是一句話裡的詞語根據不同場景存在不同意義嗎?
(語文不是我的專業)

但是看你的回復,B 選項(第二種)是自己腦補了個(啟動)進去的吧?
如果把自己腦補進去的也能當成別人的問題,估計我當年高考語文就滿分了。

------------------------------------------------------------------------------
對了,最後澄清下,
我不是百度的人,
而且我很討厭百度的東西,特別是當年的全家桶事件,在我心中它和 3721 沒什麼區別了。
2019-12-29 16:40:58 +08:00
回复了 CallmeDredd 创建的主题 程序员 大家帮忙看看百度网盘的这个逻辑设计合不合理
2019-12-29 16:39:14 +08:00
回复了 CallmeDredd 创建的主题 程序员 大家帮忙看看百度网盘的这个逻辑设计合不合理
@CallmeDredd @willxiang
百度網盤是彈窗自動倒數 30 秒才關機的。
你們上來就噴真的............
2019-12-29 16:38:22 +08:00
回复了 CallmeDredd 创建的主题 程序员 大家帮忙看看百度网盘的这个逻辑设计合不合理
你不用假設了,我測試了,選擇 完成關機 後退出,再打開依然是選擇著的。
我覺得沒任何毛病,
默認此功能是關閉的,
我主動打開了它,
中間無論發生什麼事,
再次打開應該要按我主觀的設置為主,而不是又恢復默認。

對了,99.9%為什麼便宜百度了?
如果你不想掛機,那你可以根據預計完成時間,添加個計劃進去關機啊,只要下載完畢或者達到指定時間就關機不就行了?
如果按標題來說,可否走 ws 協議?


進入頁面->輸入驗證碼->建立 ws 通道->ws 判斷驗證碼-->正確執行返回並計次->達到 100 次重走輸入驗證碼流程。
錯誤重來<-|
“最终我还是采用简单粗暴的方法:rand(1,100)>98 && show_captcha();”

看了下,你好像是想反爬,
你這個方法我直接棄用這次請求,再發起新的請求,不就繞過去了嗎?
基本上是這樣的,
第一步他們跑來出一堆報告,
然後你們根據報告整改,途中可和他們商量如何改。
然後再提交一次上去他們審核確認。
如果這次過了就不會產生其他費用,
如果第二次提交不過再次整改,則需要另外付費。
我們那時候都是和他們下派的搞好關係,然後整改時候他們也說了一些重點讓我們搞。
我們那時候是 ZF 的項目,但是其實就幾個展示頁面的事情,款項 3xxx。
然後等保就要 8W。
1 ... 29  30  31  32  33  34  35  36  37  38 ... 46  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1175 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 17:49 · PVG 01:49 · LAX 09:49 · JFK 12:49
Developed with CodeLauncher
♥ Do have faith in what you're doing.