维基百科:互助客栈/技术
 |
發表前請先搜索存档，參考舊討論中的内容可節省您的時間。 |
 存檔 |
|---|
|
2005年 12 月 |
- [公告] 中文维基百科第十八次动员令于2020年7月11日至9月13日举行，欢迎参与。
- [請求] 請協助處理字词转换的地区词候选以及修复请求積壓。
- [請求] 請社群討論「模版編輯員」做為錯字重定向是否妥當。
- [公告] Featured picture模板全保護問題、外部連結指引修訂、增设“模板编辑员”权限组及可靠來源指引修訂已經通過。
- [公告] 用户名方针修订及增设小作品化提案正在進行公示，如有意見請盡快提出。
- [討論] 方针區正在討論中国的用法、DYK評選留言的問題及將「Wikipedia:拉票」作為態度指引或方針的問題，請踴躍參與討論。
- [討論] 技术區正在討論利用脚本实现半自动化提报内容评选，請踴躍參與討論。
- [討論] 条目探讨區正在討論統一所有分類中「橋樑」與「橋梁」之繁體用字問題、Template:Infobox bilibili personality内小电视成就的图标问题及关於“歌手·当打之年”，請踴躍參與討論。
- [討論] 其他區正在討論第2000個GA紀念問題、香港社群對國安法在香港施行對香港編輯實際影響的關注及为典范条目/特色列表评选新增即时不合标准之规定，請踴躍參與討論。
- [討論] 维基共享资源互助客栈之中文版正在討論建立繁簡與地區詞轉換方針，請踴躍參與討論。
| 發言更新圖例 |
|---|
|
|
|
|
|
| 特殊狀態 |
| 已移動至其他頁面 或完成討論之議題 |
| 手動設定 |
| 當列表出現異常時， 請先檢查設定是否有誤 |
Reply tool as a Beta Feature[编辑]
Hello, User:Taiwania Justo and other editors,
I have good news for you.
The mw:Editing team held the mw:Talk pages consultation 2019 last year. mw:Talk pages project/replying is the first major tool that they built because of that consultation.
Right now, the tool is available at the French, Arabic, Dutch, and Hungarian Wikipedias as a Beta Feature. The Editing team is making a short list of Wikipedias that will get the new 'Reply' tool as a Beta Feature next week. About 8 more Wikipedias will get access to the Reply tool. It will be opt-in. To use the tool, you will have to go to Special:Preferences#mw-prefsection-betafeatures and turn on the tool. If you don't turn it on, nothing will change for you.
The Chinese Wikipedia is currently on their list. I have been using the Reply tool at many wikis, and I love it. However, if, for some reason, you have changed your minds for any reason and do not want this Wikipedia to get access to this tool next week, then please tell me as soon as possible. Otherwise, I will assume that it's okay. Whatamidoing (WMF)（留言） 2020年7月30日 (四) 22:35 (UTC)
- You can test it on this page, by clicking https://zh.wikipedia.org/wiki/Wikipedia:互助客栈/技术?dtenable=1 if you want. Whatamidoing (WMF)（留言） 2020年7月30日 (四) 22:37 (UTC)
- The Beta Feature is ready! You can go to Special:Preferences#mw-prefsection-betafeatures and turn on "讨论工具" to use it. Then go to any normal, wikitext-based talk page and look for the [ 回复 ] button at the end of existing comments/signatures. Whatamidoing (WMF)（留言） 2020年8月6日 (四) 19:53 (UTC)
Hello, User:Taiwania Justo and other editors,
Something broke yesterday with the Reply tool. The ticket is phab:T259855. The main symptom was that English-language namespaces were replaced with the local content language and that some characters were percent-encoded. At this stage, there should be no more bad diffs being created. Please check for bad diffs. The Editing team apologizes for the difficulties. Please ping me if you see new problems. Whatamidoing (WMF)（留言） 2020年8月7日 (五) 17:36 (UTC)
- Hello, it seems that the tool doesn't work on this Wikipedia nowadays? When I press the [回复] button, a pop-up window appeared and said that "由于wikitext中的错误，本页面上的评论将无法被回复。您可以通过[$1阅读文档]以了解这个错误，通过[$2在这里发帖]寻求帮助，也可以通过通过[$3打开全页编辑器]修复这个错误。"——BlackShadowG（留言） 2020年8月8日 (六) 11:44 (UTC)
- @BlackShadowG：現在可以了吧，是有人在本頁加入造成Lint錯誤的語法所造成，至於您無法正常地看到錯誤訊息也是另一個錯誤，現在應該也修復了？--Xiplus#Talk 2020年8月8日 (六) 13:56 (UTC)
- 现在可以了，谢谢您。 BlackShadowG★（留言） 2020年8月9日 (日) 12:55 (UTC)
- @BlackShadowG：現在可以了吧，是有人在本頁加入造成Lint錯誤的語法所造成，至於您無法正常地看到錯誤訊息也是另一個錯誤，現在應該也修復了？--Xiplus#Talk 2020年8月8日 (六) 13:56 (UTC)
請為檔案上傳精靈適配非自由內容使用依據模板功能[编辑]
現行的精靈不知道在做什麼，例如，我上傳了一張電子遊戲畫面截圖，在介面裡已經勾選了遊戲截圖的選項，結果出來還是用了{{Non-free use rationale 2}}，而不是更符合的{{Non-free use rationale video game screenshot}}，另外紅色*的「必填選項」都填寫完了，上傳後模板竟然提示replaceability跟commercial參數沒有填寫，違反WP:NFCC，還要手動處理，那麼這倆不是應該預設就放在「必填選項」裡面嗎？希望能夠檔案上傳精靈適配非自由內容使用依據模板功能，勾什麼選項就出來什麼模板。—— Eric Liu 創造は生命（留言．留名．學生會） 2020年7月31日 (五) 03:32 (UTC)
- 支持，现在有很多非自由檔案文件依據模板，这些模板可以协助编者（尤其是新手）写出比较出色的非自由文件的合理使用依据，如果把这些模板中的已经较为成熟的模板加入上传精灵会很方便，我每次传完Logo图片还得手动把{{Non-free use rationale 2}}替换成{{Non-free use rationale logo}}。——BlackShadowG★（留言） 2020年8月8日 (六) 11:50 (UTC)
- 因为那会导致程序行数增多，所以编程的人不喜欢这么做。他们更希望用同一个东西处理更多的情况。--1=0，欢迎加入WP:維基百科維護專題 2020年8月8日 (六) 12:59 (UTC)
- @Alexander Misel：那至少也要處理“上傳後模板竟然提示replaceability跟commercial參數沒有填寫，違反WP:NFCC，還要手動處理”的問題，我想到Wcam就心煩。SANMOSA SPQR 2020年8月9日 (日) 03:23 (UTC)
- (＋)支持。另@Sunny00217：在下半年前曾向您反映过相关问题，上传文件向导的部分选项并不会填写{{Non-free use rationale 2}}的replaceability跟commercial参数，如果是logo也不会填入author。每次上传完后都要再换模板或者修改参数十分麻烦。--Tim Wu（留言） 2020年8月9日 (日) 03:36 (UTC)
- 當然了，如果是希望不要顯示警告的話當然是回退到添加那些七雜八雜的東西前，但是這樣一直用也不是辦法，可能還是得改js，但看都看不是很懂結構個更何況是還要提出修改方案......-- Sunny00217 2020年8月9日 (日) 10:29 (UTC)
就了解一下情况[编辑]
新用户不能用户名中英混合？--Herobrine 303🍀留名 疫情尚未结束，切勿放松警惕!🦠 2020年8月1日 (六) 03:57 (UTC)
- 不行。以“中Eng”測試的結果是：“已禁止使用使用者名稱 "中Eng"，以避免混淆或欺騙使用者名稱：包含不兼容的混合文字。 請使用其他使用者名稱。”SANMOSA SPQR 2020年8月9日 (日) 03:19 (UTC)
能幫忙把Template:DC8/talk右上角半保護模板圖示只顯示一個嗎？[编辑]
完成，感謝，問題已修復。--- 下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
如標題，經查發現重複顯示了，可不知道問題出在哪（可能有bug，其它的DC都正常顯示一個半保護模板圖示而已），希望能獲得解決。--Z7504非常建議必要時多關注評選（留言） 2020年8月1日 (六) 15:19 (UTC)
- 本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
Tech News: 2020-32[编辑]
維基媒體技術社群现發出最新技術新聞。請告知其他用戶以下變更。當然，未必所有變更都會影響閣下。有提供其他語言的翻譯版本。
问题
- 在7月23日星期四的17:50至17:59 UTC之间，Wikidata Query Service的所有查询都失敗了，有些查询在更長的时间段上失敗。 [1]
- 在过去的几周，跨语言链接的順序錯誤，此問題已在兩週前的技術新聞中提到，现已修复。 [2]
- 全局偏好設定的「使用旧版Vector皮肤」选项目前有问题，开发人員正在進行修复。 [3]
- 在維基共享資源上，Wikibase擴充功能中的一個錯誤導致「移動」和「建立」保護類型在主要（Gallery）命名空間中被停用，無法設定新的保護，現存的保護也無法作用，導致允許了某些原本不應被允許的頁面移動和建立。現已修復。 [4]
本週後期變更
- 影片播放器將變得更簡單、更現代，目前的測試版功能將在本週成為維基百科以外的維基上所有人使用的影片播放器，舊版播放器將移除。 [5]
- 使用者的
global.js和global.css頁面即將也在移動版網站上載入，您可以閱讀說明文件來了解如何避免將樣式套用到移動版外觀上。 [6] 
MonoBook外觀上的searchGoButton識別字現在改為searchButton，這會影響CSS和JS小工具，可以在T255953上找到遷移說明。這個更改曾在第27期新聞中提到過。- 機器人操作者可以使用Pywikibot來定時存檔討論，為了防止存檔過大而由機器人使用的
counter變數行為被修改。 [7] 
MediaWiki新版本將於8月4日部署至測試維基及MediaWiki.org，8月5日部署至非維基百科站點及部分维基百科，8月6日部署至所有站點，參見日曆。
MediaWiki技术新闻由技术新闻作者制作并由MediaWiki信息递送送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。
2020年8月3日 (一) 15:43 (UTC)
- mediawiki:prefs-vector-enable-vector-1-label是不是应该改成“使用旧的vector皮肤”才对？--百無一用是書生 (☎) 2020年8月4日 (二) 01:04 (UTC)
- translatewiki那边已有人改了。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年8月4日 (二) 01:18 (UTC)
如何修改用户common.js实现中文与外文、数字之间含半角空格[编辑]
根据Wikipedia:格式手册#空格，这些情况不应该有空格，但是为了视觉上更加美观，所以来提这个问题。
var reg = /(?:([0-9A-Za-z_])([\u4e00-\u9fa5]))|(?:([\u4e00-\u9fa5])([0-9A-Za-z_]))/g;
$('.mw-parser-output').textContent = $('.mw-parser-output').textContent.replace(reg, '$1$3 $2$4');
var reg = /(?:([0-9A-Za-z_])([\u4e00-\u9fa5]))|(?:([\u4e00-\u9fa5])([0-9A-Za-z_]))/g;
var result;
$('.mw-parser-output).each(function () {
while( match = reg.exec(targetText) !== null ) {
this = this.replace(reg, "$1$3 $2$4");
}
});
str = document.getElementsByClassName('mw-parser-output')[0].outerText;
let s1 = /([0-9A-Za-z_])([\u4e00-\u9fa5])/g;
let s2 = /([\u4e00-\u9fa5])([0-9A-Za-z_])/g;
temp = str.replace(s1, "$1 $2");
str = temp.replace(s2, "$1 $2");
--Hakuryuu讨论★ 2020年8月3日 (一) 20:14 (UTC)
多個不同頁面的介面訊息以HTML原樣顯示的問題[编辑]
已知Bug，僅於此通知。--Xiplus#Talk 2020年8月4日 (二) 04:08 (UTC)
刚发现移动版页面低端的最后修订历史，也就是绿色的那一栏的内链显示异常，用户名变成URL地址。--百战天虫（留言） 2020年8月4日 (二) 06:02 (UTC)
提议利用脚本实现半自动化提报内容评选[编辑]
想问下大家，能不能像这次动员令一样制作一个脚本实现半自动化提报内容评选，省去手动填报模板参数的功夫？--百战天虫（留言） 2020年8月5日 (三) 05:06 (UTC)
- 如果技術上辦的到連主持人都能省下填寫模板參數的時間，那當然(＋)支持。不過前提得真的辦的到，討論頁在使用過{{Article history}}後可以一併正確顯示
二哈，要不然還是手動填寫比較妥當。--Z7504非常建議必要時多關注評選（留言） 2020年8月5日 (三) 05:47 (UTC) - 当然(＋)支持，不过技术上的问题可不少。--👻Cryberghost 2020年8月6日 (四) 11:23 (UTC)
- @Cryberghost：比如说？--百战天虫（留言） 2020年8月7日 (五) 16:53 (UTC)
二哈，要不然還是手動填寫比較妥當。--Technical Wishes: FileExporter and FileImporter become default features on all Wikis[编辑]
The FileExporter and FileImporter will become a default features on all wikis until August 7, 2020. They are planned to help you to move files from your local wiki to Wikimedia Commons easier while keeping all original file information (Description, Source, Date, Author, View History) intact. Additionally, the move is documented in the files view history. How does it work?
Step 1: If you are an auto-confirmed user, you will see a link "Move file to Wikimedia Commons" on the local file page.
Step 2: When you click on this link, the FileImporter checks if the file can in fact be moved to Wikimedia Commons. These checks are performed based on the wiki's configuration file which is created and maintained by each local wiki community.
Step 3: If the file is compatible with Wikimedia Commons, you will be taken to an import page, at which you can update or add information regarding the file, such as the description. You can also add the 'Now Commons' template to the file on the local wiki by clicking the corresponding check box in the import form. Admins can delete the file from the local wiki by enabling the corresponding checkbox. By clicking on the 'Import' button at the end of the page, the file is imported to Wikimedia Commons.
If you want to know more about the FileImporter extension or the Technical Wishes Project, follow the links. --For the Technical Wishes Team:Max Klemm (WMDE) 2020年8月6日 (四) 09:14 (UTC)
- 此改動不會對我們有影響-- Sunny00217 2020年8月6日 (四) 10:54 (UTC)
- 有影响。配置文件居然放在mediawiki里边，而不是存储在本站的Mediawiki名字空间下？现在一大堆非自由版权的文件都显示可以移动到commons。--Antigng（留言） 2020年8月7日 (五) 14:47 (UTC)
- 例如哪個檔案？--Xiplus#Talk 2020年8月8日 (六) 13:25 (UTC)
- ，比如File:Linyi_jichang_logo.jpg。--Antigng（留言） 2020年8月8日 (六) 13:56 (UTC)
- 例如哪個檔案？--Xiplus#Talk 2020年8月8日 (六) 13:25 (UTC)
維基百科:用戶框/政治團體上方的小圖標出現BUG[编辑]
維基百科:用戶框/政治團體上方的小圖標出現明顯大小不一的情況，我對照了編輯紀錄還是找不出來問題出在哪裡。--Cbls1911（留言） 2020年8月6日 (四) 16:30 (UTC)
垃圾链接过滤器有时候连T:URL也不让加[编辑]
如题，往U:Rowingbohe/玉环市的条目信息框加入{{URL}}时出现。错误：垃圾过滤器禁止保存您刚才提交的页面，这可能是由于您所加入的外部网站链接所产生的问题。您可以使用此工具测试您加入的链接匹配哪条本地或全域垃圾链接黑名单，并请参见外部链接使用指引。如果您确认垃圾过滤器封锁有误，请在垃圾链接黑名单讨论页面提交修复请求。如果您只是允许一个特定的链接，而不是要移去黑名单上的整个链接，您可以到垃圾链接白名单的对话页提出请求。以下文本触发了我们的垃圾链接过滤器：%20
但刚刚在其他条目复现时未见此问题，很奇怪。--—Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月6日 (四) 20:19 (UTC)
- Spamblacklist功能不保存触发黑名单的问题编辑，所以我无法确切地知悉您到底在这个页面里干了什么事情。但是根据垃圾链接黑名单日志，您试图加入的是"http://www.yuhuan.gov.cn%20www"这个非法的网址，它与黑名单规则%20是匹配的。您加入的模板，在展开以后包含的链接肯定是非法的。可能是模板的问题，也可能是您的输入一开始就是非法的。为了搞清楚，请您提供相应编辑的具体内容，谢谢。--Antigng（留言） 2020年8月7日 (五) 15:03 (UTC)
- 我刚开始进行的是大幅扩充，遇到拦截分段查看，发现问题后进行多次复现，源代码直接加入{{URL|和}}。—Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月10日 (一) 10:07 (UTC)
无法重现，Special:Diff/61099224。--Antigng（留言） 2020年8月10日 (一) 10:34 (UTC)
- 1.我指的是在http://www.yuhuan.gov.cn左侧加入
{{URL|，右侧加入}}（非要我加上<code>？）2.本人发讨论串时候已经说了在其他页面无法复现，请见第二段，所以很奇怪。谢谢合作。—Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月10日 (一) 10:44 (UTC) - 刚刚复现成功，本人授权您编辑此用户页以复现。—Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月10日 (一) 10:46 (UTC)
- 你有八成加入的文本是这个：{{URL|http://www.yuhuan.gov.cn }}，告结。
- P.S. 如果你不理解原理的话，我只能说：Cewbot大法好！--Antigng（留言） 2020年8月10日 (一) 10:50 (UTC)
- 1.我指的是在http://www.yuhuan.gov.cn左侧加入
- 我刚开始进行的是大幅扩充，遇到拦截分段查看，发现问题后进行多次复现，源代码直接加入{{URL|和}}。—Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月10日 (一) 10:07 (UTC)
无法重现，請求翻譯Template:Infobox beauty pageant模板[编辑]
請求熟悉翻譯模板操作的幫忙翻譯en:Template:Infobox beauty pageant到中文維基。－日月星辰 | 留言簿 2020年8月6日 (四) 22:11 (UTC)
- 翻译模板其实就是把英文那边的内容贴过来，把label翻译一下，没有什么难的。你可以自己尝试一下。另外最好还要把模板的doc翻译一下--1=0，欢迎加入WP:維基百科維護專題 2020年8月7日 (五) 01:20 (UTC)
囧rz...，所以還是想請熟悉翻譯模板的幫忙。－gg.sxbb.me[编辑]
(？)疑問：某編者的這個編輯、這個編輯、這個編輯、這個編輯，將ref中books.google.com網址冠上gg.sxbb.me，他說是視覺化編輯自動帶入的，請問這是正常的嗎？--Hjh474（留言） 2020年8月7日 (五) 10:57 (UTC)
说几句重话。使用第三方反向代理编辑而不仅仅是阅读，这件事情从一开始就是错的。无论是直接访问，还是使用诸如VPN，TOR之类的工具间接访问本站，wmf服务器的运作方式，以及所涉及的协议（HTTPS，TOR等等）保证了在成功的情况下，你所接收到的内容是绝对完整与正确的。但是第三方反向代理不同，它根本就在最底层就把https请求和/或响应给拆开了，它可以对收到的数据作任意修改，再转发给使用这些反向代理的用户，而在用户一端，是没有机制去保证他/她所获取的内容确实是wmf的服务器想发给他/她的——这内容可不仅限于页面内容，也可以是js脚本——也自然没有机制去保证第三方没有窃取相应信息。
纵观本站使用被某些编者使用得比较频繁、允许编辑的第三方反向代理，其中有多少在技术上可以做到与wmf提供同等的安全性？那些使用源自中国大陆的VPS提供者来搭建的第三方反向代理，能否从根本上避免为响应北京政府的执法请求，而造成用户隐私数据泄露的问题？对wmf而言，隐私权的重要性自然是不言而喻的，这也是其激进地推行HSTS的其中一个原因。这些站点中，有些居然连单独的TOU或介绍隐私权政策的页面都没有，却在另一方面暗示编者可以透过申请WP:IPBE加以编辑——从技术上说，有了IPBE，即使再严厉的IP封禁也奈何不了使用如此站点加以编辑的编者；然而这种在技术上可行的行为，又是否与wmf保护用户隐私权的精神相符呢？本人持强烈的保留意见。
最后谈谈技术问题。第三方反向代理为了改善用户体验，会对链接甚至文本中的链接进行一定程度的重写，将其改为指向反向代理的链接。这正是造成上述问题的根源。是否可能对反向代理的规则进行优化，以保证浏览的时候不替换，编辑的时候替换，给用户提供完全等同于原站的编辑体验呢？答案当然是否定的。想象一下如下的两个场景：
- 某脚本利用本站的解析器提供的html内容配上更好的排版方式，来改善读者的浏览体验。
- 某脚本利用本站的解析器提供的html内容，做出了一个更好的可视化编辑器。
无论是何者，都需要透过相同的api向本站服务器请求html内容。前者要求第三方反向代理在工作时重写链接，而后者要求第三方反向代理不重写链接，这是做不到的。当然，如果一律重写链接，还可以在后续用户提交编辑的POST请求中将链接替换回来——但另一方面，如果用户真想探讨这个反向代理站的问题呢？不又是错误替换了么？
当然目前真正的ve是通过action=visualeditor工作的，你或许可以辩解在脚本制作者配合的情况下，通过action=parse和action=visualeditor就可以区分这两个场景。但是不要忘了parsoid（现在已经用php重写了）在将来是要取代老版解析器，并移入mediawiki的core里边的，在将来就没这种差异可以利用了。
--Antigng（留言） 2020年8月7日 (五) 16:03 (UTC)
- “使用第三方反向代理编辑而不仅仅是阅读，这件事情从一开始就是错的”——何解？什么人能让GFW网开一面。您我能访问或是编辑不代表所有人都能如此，给想要贡献的人一个途径，也不错。何不食肉糜？
- “你所接收到的内容是绝对完整与正确的”——不一定，GFW或区域网关都有能力做到MITM，修改的数据到了用户侧后依然会被认为是“安全的”。
- “也自然没有机制去保证第三方没有窃取相应信息”——“非礼勿视，非礼勿听，非礼勿言，非礼勿动。”不是所有人都是恶意的，维基用户的数据，收集来除了占用空间之外也没什么其他的意义。
- “有多少在技术上可以做到与wmf提供同等的安全性”——您以为WMF那套很安全？
- “使用源自中国大陆的VPS提供者来搭建的第三方反向代理，能否从根本上避免为响应北京政府的执法请求，而造成用户隐私数据泄露的问题”——据我所知，没有反代使用大陆VPS的。“北京政府的执法请求”又是什么。
- “这也是其激进地推行HSTS的其中一个原因”——HSTS和您说的其实没多大关系，HSTS只验证HTTPS证书链完整而不验证发布者。即只要证书链完整就都是合规的。
- “有些居然连单独的TOU或介绍隐私权政策的页面都没有”——有了又能如何，没有又能如何，一纸空文罢了。
- “另一方面暗示编者可以透过申请WP:IPBE加以编辑”——还是那句话：“何不食肉糜”。
- “这种在技术上可行的行为，又是否与wmf保护用户隐私权的精神相符”——您完全信任WMF，但为什么对第三方持百分百恶意。
- “是否可能对反向代理的规则进行优化，以保证浏览的时候不替换，编辑的时候替换，给用户提供完全等同于原站的编辑体验呢？答案当然是否定的”——答案当然是肯定的。
- “前者要求第三方反向代理在工作时重写链接，而后者要求第三方反向代理不重写链接，这是做不到的”——这也是做得到的。
- 我虽然不知道您是什么专业，但相关技术上，您不精；道德上，您这百分百的恶意推测实在是令人不敢苟同。对他人稍稍善意一些，也好。
- --安忆Talk 2020年8月8日 (六) 05:14 (UTC)
- 我稍微总结下，您的意思无外乎也就是这几点：我能用，别人不能用不关我事，是他们自己不行；您的数据超级值钱，所有人哪怕采取各种手段，也都要去得到它们；WMF百分百安全，第三方百分百是小偷。 --安忆Talk 2020年8月8日 (六) 05:25 (UTC)
- 以及IPBE，WMF完全可以弄一个信任代理名单，对于名单上的服务器，信任其传递的X-Forwarded-For标头（其包含用户的真实IP），这样就不用IPBE了（因为代理服务器的IP总是被封禁的，WMF现今又只识别实际连接它的IP，X-Forwarded-For标头全都被舍弃），也不用担心XFF标头会被伪造，因为XFF标头是由用户实际连接代理服务器的IP构成的——代理服务器可信，其发送的标头即可信。 --安忆Talk 2020年8月8日 (六) 05:35 (UTC)
- --安忆Talk 2020年8月8日 (六) 05:14 (UTC)
- 感謝資訊分享，頗有收穫。若如此，編者提交編輯前是不是應該檢查與清理？強迫（點選ref的）讀者連上gg.sxbb.me，似乎不太好，編者雖無惡意，但是反代站如此替換似乎並非善意。--Hjh474（留言） 2020年8月8日 (六) 06:00 (UTC)
- (：)回應：
- “给想要贡献的人一个途径，也不错”：账户安全性既关乎个人信息的安全，也关乎本站的安全。它并非完全由用户掌控，进而可以随意让渡而换取其它便利的事物。某commons管理员账户被盗，导致站点common.js被插入恶意挖矿脚本的教训还不够深刻么——事后我们设置了界面管理员，但如果用户不注重帐户安全，又如何能保证这样的问题将来不会再发生？就算届时您的账户真被盗用了，我们把您除权、封禁甚至禁制了，对本站造成的损失能弥补么？而且不要以为不是管理员，账户的安全性就不重要。回退员就仅仅有一个回退功能么？别忘了他/她们还可以查看过滤器规则和细节。巡查员只能巡查么？别忘了他/她们自己有巡查豁免权。大量信息发送者，机器人，全域重命名员，这些权限的重要性我还有必要解释么？
- “不一定，GFW或区域网关都有能力做到MITM，修改的数据到了用户侧后依然会被认为是‘安全的’。”：只要你不信任由中国大陆控制的CA机构颁发的根证书，通过什么途径能实现这样的目标？这种说法从根本上是颠覆了HTTPS原理，完全无法理解。
- “您以为WMF那套很安全？”：事实1：根据WMF发布的透明度报告，其声称自成立以来从未响应过非传统意义上的民主国家的政府提出、涉及用户隐私的执法请求；事实2：早在十年以前，WMF就透过IPSEC来保护数据中心间/数据中心内部缓存服务器间的通信，在五年以前开始以HTTPS来保护数据中心内部，缓存服务器与后端应用层之间的通信。
- “HSTS和您说的其实没多大关系，HSTS只验证HTTPS证书链完整而不验证发布者。即只要证书链完整就都是合规的。”：我不要您觉得，我要WMF觉得。早在WMF全面启用HSTS之前的2013年，WMF的职员就已经意识到，启用HSTS一方面可以防范部分中间人攻击的情形，另一方面可能会让部分封杀HTTPS的地区彻底失去访问维基的可能性。最后它还是决定这样做了，中国大陆也在事实上失去了直连部分维基站点的可能性。使用第三方反向代理进行登录和编辑，则恰恰是对这样的原则的妥协。
- “据我所知，没有反代使用大陆VPS的”：请您回到这个讨论的标题，sxbb.me乃中国大陆注册的初创企业“师兄帮帮”，搭在腾讯云之上。
- “有了又能如何，没有又能如何，一纸空文罢了”：这是网站向用户的承诺。连一纸空文都没有，届时倘若网站真的侵犯到了用户的权利，用户如何维权？
- “您完全信任WMF，但为什么对第三方持百分百恶意”：请勿打稻草人靶子。本人并没有断言第三方代理提供者的动机如何，本人强调的是机制。没有机制保证第三方代理会以怎样的方式中继来自WMF服务器的内容，没有机制保证第三方代理如何使用用户的个人数据，部分第三方代理甚至没有在纸面上保证会如何对待这些问题。这本身就是一个问题，无论第三方服务是出于善意还是恶意。
- “这也是做得到的。”：请解释。
- “我虽然不知道您是什么专业”：物理。
- “但相关技术上，您不精”：请指出。
- “道德上，您这百分百的恶意推测实在是令人不敢苟同”：如上，请勿立稻草人。本人没有对第三方反向代理提供者的动机作出任何程度的断言。
- “我能用，别人不能用不关我事”：这的确是本人的想法，因而在过去，我一直是主张按照IPBE方针的字面意思授予相应权限的。本人亦多次对本站滥发IPBE权限的现状有所不满。
- “是他们自己不行；您的数据超级值钱，所有人哪怕采取各种手段，也都要去得到它们；WMF百分百安全，第三方百分百是小偷”：稻草人，这不是本人的想法。本人在乎的是用户隐私和本站自身的安全。
--Antigng（留言） 2020年8月8日 (六) 06:59 (UTC)
- 我知道您在担心什么，也完全能够理解。安全性是重中之重，您担心用户遇到恶意站点，但反代站不都是钓鱼的，总会有正常的站点。像我最开始说的“给想要贡献的人一个途径”，我不觉得有任何问题。虽然用户遇到这二者中的哪一种是完全看运气。但是否继续使用，用户自己还是有选择的自由。俗话说：“用人不疑，疑人不用”。最重要的是，如果在大陆想要浏览或编辑维基百科，无外乎采用这几种方式：“VPN、反代、Tor”，显然，Tor对一般用户来说太遥远，VPN和反代站是最常用的选择。但您认为这两种技术哪种相对安全呢？我认为是反代站——二者的架设者都可以看到一切，但显然VPN能看到的更多。安全是相对的，总不该因噎废食。
- 您信任WMF发布的透明度报告，那为什么就不能多给第三方一些信任呢？使用反代站进行登录和编辑，真的是对安全性的妥协吗？不是所有人都是好人，但也不是所有人都是坏人。您没有断言提供者的动机，您说您强调的是没有机制保证内容的安全，没有机制保证用户的隐私，那么，您上面的回复是使用了何种绝对安全的手段作出的呢？
- 您说您在乎的是用户隐私和本站自身的安全。安全性方面我上两段说了一些我的想法，用户隐私方面，我个人认为，没有价值的用户数据或是隐私没有窃取和窥探的意义。我也搭建了一个反代站：技术上，我可以看到一切；但道德上，我知道自己不能那样做；而利益上，那堆数据对我毫无意义，完全没有犯罪的动机。[開玩笑的]
- 至于您提到的sxbb.me，那是主域名。其用来反代的域名是这个，是香港阿里云。
- 至于您提到的两个功能性方面的问题，您不要忘了，使用者是人，而不是机器。可以把选择发给前端让用户自己选择。
- 我最想说的其实只有一句话：“不该一棒子打死所有人”，仅此而已。
- 其实有一些站点我也看不上眼，我在这里提到了一些例子和预想的标准。除非GFW被拆了，那么反代站、VPN或是其他的东西就不可能消失，与其说“这件事情从一开始就是错的”，不如做一个好的示范。
- --安忆Talk 2020年8月8日 (六) 10:49 (UTC)
- “给想要贡献的人一个途径不觉得有任何问题/不该因噎废食”：这一点放在WMF的语境下是值得商榷的。如果WMF认为提供这样一种相对而言安全风险比较高的途径给受网络封锁的国家/地区的编者“没有任何问题”、“不该因噎废食”，那么当初它就不会在明知风险存在的情况下，堵死明文HTTP访问本站的途径，就不会一刀切强制重定向到HTTPS，防火长城现在可能也不会采取全站点封杀这种策略——但是WMF就是这样做的，连数据中心内部这种安全风险比较低的场景也是一刀切强制HTTPS。本人的bot当初在wmflabs（现在叫toolforge）上工作的时候找了个漏洞继续明文HTTP，被WMF的人发现了还被批评教育了。
- “显然VPN能看到的更多”：从原理上完全无法理解。VPN工作在网络层，根本无从知悉应用层的东西，更何况VPN建立以后，若仍按照默认的HTTPS方式直连本站，你想知道HTTPS也不会让你知道，VPN提供者只知道你在什么时间连了什么站，交换了多少数据，而不可能知道这数据的具体内容。这就与反向代理有本质的不同。当然我不是说使用VPN编辑不对本站造成安全隐患——但这种隐患主要来自其对CU工作的干扰，而不是隐私。
- 另外需要强调的是，恐怕更为常见（或者传统意义上的）翻墙技术是使用正向代理。无论是基于HTTP的正向代理（透过CONNECT机制）还是基于SOCKS的正向代理（例如Shadowsocks），在处理HTTPS流量的时候实际作用都只是建立一条虚拟通道而已，并不会影响到应用层。
- “是否继续使用，用户自己还是有选择的自由”：选择的自由是建立在知情的基础之上的。对于一个不熟悉的用户而言，正向代理和反向代理都是“代理”，完全可能会认为它们拥有等同的安全性。--Antigng（留言） 2020年8月9日 (日) 14:51 (UTC)
- “给想要贡献的人一个途径”是我觉得没有问题，不需要WMF认为如何如何。WMF那套哪怕再安全，也是它们内部的安全，当使用代理的时候，这种安全就已经是不完整的了。如果大陆的用户现在想要继续参与几乎已经全线被墙的维基媒体计划，就只能使用间接的方式，您前面几次强调了WMF的各种策略，那您能提出来一个对于大陆用户的既安全又实用便捷的访问手段吗？您对反代持反对态度，认为它们“不安全”，但我也一直在说“不该一棒子打死所有人”，因为不是所有人都是好人，但也不是所有人都是坏人。反代在现在的环境下，显然是一种不错的选择。我还是这个观点：除非GFW被拆了，那么反代站、VPN或是其他的东西就不可能消失，与其说“这件事情从一开始就是错的”，不如做一个好的示范。并且，对于一个不熟悉的用户而言，他们压根儿不会去深入了解甚至不会考虑什么安全性，对于他们，是“能用就行”，甚至是“有得用就行了”。
- 说点儿无关的：现在几乎所有反代站都是非盈利、凭热情而建的，我作为一个反代站的建立者，我个人觉得您这善意缺失的推测还是自己放在心里想想就好。这让我想起了前段时间在群里聊天遇到的一个人，他正上初中的妹妹被班主任骚扰，大家都在为其出谋划策，这时候偏偏有一个人跳出来说“万一是他妹妹勾引老师的”。有的时候，“众人皆醉我独醒”，不好。何况，对于伪装成网银的钓鱼网站来说，有其存在的意义，因为利益可观；但对于维基这套，我只在是想不出那堆没有价值的用户数据和隐私有什么窃取和窥探的意义，也就只能拿来占空间而已吧。
- 这问题很简单，如果某用户担心自己账号被盗，那他自己不用镜像站就可以了。安忆的站之前顶上就有提示了，不信任请勿登录编辑。安全和cross wall编辑总得选一个吧。您举了c站common.js被植入挖矿脚本的例子，举了界管的例子，但是用镜像站的用户真的都是界管吗？真的都可以编辑MW:Common.js吗？—Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月10日 (一) 12:01 (UTC)
- 这可能是一个安全问题，已经在Phabricator上向维基媒体基金会安全部门提交工单（见T260016）。VulpesVulpes825（留言） 2020年8月10日 (一) 07:50 (UTC)
--
如何處理[编辑]
(？)疑問：我們該怎麼做，才能不被「gg.sxbb.me」持續侵入ref呢？只能靠偶然發現+手動清理嗎？--Hjh474（留言） 2020年8月8日 (六) 11:11 (UTC)
- 一般来说，只能如此。靠手动修正。 --安忆Talk 2020年8月8日 (六) 11:20 (UTC)
- 题外话：gg.sxbb.me好像是个Google的镜像站。——BlackShadowG★（留言） 2020年8月12日 (三) 09:37 (UTC)
AF可以做到拦截某一个页面里列出的所有域名这种功能吗?[编辑]
如题。即使用AF实现类似Spamblacklist的功能，但因为是过滤器，因此较Spamblacklist更为灵活。相关讨论：[8]。--Yining Chen（留言|签名） 2020年8月9日 (日) 09:57 (UTC)
Tech News: 2020-33[编辑]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
- FileImporter and FileExporter became standard features on all Wikis during the first week of August. They help you transfer files from local wikis to Wikimedia Commons with the original file information and history intact. [9]
Problems
- The mobile skin displays a message at the bottom of the page about who edited last. This message showed raw wikitext. This has now been fixed. Some messages in Structured Discussions and content translation may still appear as raw wikitext. Developers are working on it. [10]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from August 11. It will be on non-Wikipedia wikis and some Wikipedias from August 12. It will be on all wikis from August 13 (calendar).
Future changes
- All wikis will be read-only for a few minutes on September 1. This is planned between 13:30 and 15:30 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [11][12]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
2020年8月10日 (一) 16:06 (UTC)
User talk:Xrdtj移动版分段异常[编辑]
User talk:Xrdtj#邀请您参与条目质量提升活动之后的内容在移动端均未分段，和上述段落显示在一起。PC端正常。--忒有钱🌊塩水あります🐳（留言） 2020年8月10日 (一) 17:51 (UTC)
- 未閉合的div 已修復。-Zest 2020年8月10日 (一) 22:03 (UTC)
關於Adjacent stations的問題[编辑]
有熟悉adjacent stations模板的人知道為甚麼大橋頭站的adjacent stations參數note-mid1和note-mid2內容相同，卻無法合併成一個儲存格的原因嗎？--owennson（聊天室、獎座櫃） 2020年8月11日 (二) 07:56 (UTC)
- special:permalink/61113158，猜測是{{台北捷運顏色}}的nowiki# 。-Zest 2020年8月11日 (二) 08:19 (UTC)
Twinkle更新 (2020-08-11) @efa3cd6[编辑]
- 近期變更
- 回退：已修復先前從IP段的使用者貢獻頁發起回退時，無法正確地抓取IP而在編輯摘要中錯誤顯示為「已隱藏的使用者」的問題
- 關閉存廢討論：已修復在關閉使用者命名空間的頁面時發生的崩潰問題（#137）
- 保護：已修復之前標記無限期保護模板時會出現參數錯誤的問題（#143）
- 封鎖：「確認為傀儡」的封鎖預設設定現在分為「根據使用者貢獻確定」和「使用者查核確認」，封鎖日志摘要將與選項保持一致（#144）
- 警告：已修復在結構式討論頁上無法警告的問題，並會顯示不支援自動警告層級的提示訊息（#146）
- 歡迎：新增歡迎使用者的功能，如果您不想要此功能可在偏好設定中關閉。如需增添常用的歡迎模板，請在Twinkle討論頁提出（#138）
- 偏好設定：已移除「在這些類別的回退後打開使用者討論頁」中無用的「恢復此版本」選項（#148）
如果近期變更有任何錯誤，或是認為未來變更會造成任何問題，請在Twinkle討論頁、互助客棧技術版或Github擇一報告。--Hamish論 2020年8月11日 (二) 08:02 (UTC)