簡體   English   中英

WordPress 和 phpMyAdmin - 404 無處不在

[英]WordPress with phpMyAdmin - 404's everywhere

因此,我一直在嘗試對自定義 WordPress 主題進行一些更改,該主題引入了對儀表板的全面檢修。 我一直發現我需要修復的原始主題的小問題(導入新帖子時沒有正確檢查重復的帖子、帖子元數據沒有正確存儲、帖子沒有被分類到正確的類別等)

當我一直在處理這個問題時,我需要無數次地查看和修改數據庫,以查看主題對數據庫所做的事情或修復它搞砸的事情。 Unfortunately I was unable to install phpMyAdmin so I've been making changes by directly typing SQL and inserting it into the theme in appropriate places, then having the script die() so I can see the output of my SQL.

突然間,我發現我可以找到一個插件,它將 phpMyAdmin 功能集成到 WordPress 中。 所以我安裝了 wp-phpMyAdmin。

在我嘗試實際任何事情之前,一切似乎都很順利。 我可以查看表格、查看行並查看所有內容。 但是當我嘗試編輯一行或刪除一行時,我被重定向到 404 錯誤,說我碰巧訪問的 phpMyAdmin 的任何部分(例如, tbl_row_action.php )都不存在。 如果我 go 直接到這些頁面而不提交表單來編輯或刪除行,那么它們工作得很好,我收到一條錯誤消息,我的 SQL 查詢是空白的。

有沒有其他人經歷過這個? 我真的無法弄清楚它發送 404 的確切原因或位置。這絕對是荒謬的。

編輯 - 更多信息:

我了解到,當 phpMyAdmin 使用sql_query參數集調用sql.php時,我只會收到 404 錯誤

編輯(再次) - 進一步更新:

當 sql_query 包含有效查詢時,我只會收到 404 錯誤。 瀏覽sql.php (我沒有花太多時間看,請注意)我注意到它似乎解析了查詢並確定你是否在SELECTDELETE檢查, DROP 。您的用戶權限。 可能和這個解析代碼有關。

以下查詢沒有給我 404:

test
SELECT test
SELECT test FROM test
SELECT test FROM post_meta
DELETE
DROP
DROP test

以下給了我一個404:

SELECT * FROM test
SELECT * FROM post_meta
DELETE FROM
DELETE FROM test
DELETE FROM post_meta
DROP TABLE
DROP TABLE test

更多編輯 -

所以在 sql.php 的最頂部,我放置了這行代碼:

die("Test");

當我進行上面列出的錯誤查詢時,它不會死。 它直接進入 404 消息。 顯然,這與 WordPress 的重定向腳本有關,與 phpMyAdmin 無關

最終編輯 -

我已經做了很多研究,並且一直在研究 WordPress。

我高度懷疑我遇到這個問題是由於一些新的 WordPress 安全功能。 舊版本的 WordPress 顯然用於允許將 SQL 輸入到 URL 中,這帶來了巨大的安全風險。 因此,他們現在不允許通過 URL 傳遞 SQL 是可以理解的。 就在模板之前, is_404()的值被設置為 true。 它在WP::parse_request()中設置(由WP::main()調用,由wp()調用,在wp-blog-header.php

任何時候在請求的 URI 中任何地方有可疑的SQL查詢時,我都會被踢到 404 頁面。 我想改變這種行為,同時盡可能少地修改 WordPress 內核。 我需要一個非常擅長 WordPress 的人來幫助我。 我認為存在涉及 $wp_rewrite 變量的答案,該變量包含大量 URL 重寫規則。

問題終於發現了——

對於任何有興趣找到這篇文章或正在關注它或只是遇到類似問題的人,我終於找到了 404 錯誤的來源。 它根本不在於 WordPress。 問題落到了 mod_security 上,這是一個 Apache 模塊,它可以防止任何看起來可疑的請求(包括請求 URI 中帶有 SQL 的請求)

永遠記得正確設置你的 mod_security 設置。

WordPress 不應干擾 phpMyAdmin,因為插件將其加載到隔離的 iframe 中。

作為他對項目的規范之一,他只希望在他的服務器上安裝 WordPress...

盡管如此,該插件仍然是phpMyAdmin (盡管在 WordPress UI 中“包裝”)。 換句話說,您已經安裝了它;)

...避免更新和維護其他軟件的麻煩...

在談論網絡應用程序時,“軟件”可能是一個危險的術語——這並不是說根本不使用它,但對於某些人來說,它可能會讓人聯想到藍屏和運行時錯誤;)

換句話說,只需強調 PMA 只是服務器上的文件集合——它沒有自己的數據庫,它實際上是無狀態的,並且刪除就像RMD /phpmyadmin一樣簡單。

...他希望能夠從 WordPress 儀表板進行所有必要的管理更改

盡管我已經提出了這些觀點,但如果儀表板中的數據庫管理訪問絕對必要,我將編寫一個使用phpMiniAdmin的快速替代方案(這就是我奇怪地偶然發現這個問題的方式,)。 我很樂意分享給你試用。

As @molnarm pointed out in the comments, why not just removed phpMyAdmin and connect to MySQL over SSH, using something like MySQL Workbench or Sequel Pro .

您將有一種更簡單、更快捷的方式與 MySQL 進行交互,並且可以刪除 phpMyAdmin 的噩夢。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM