Home >Backend Development >PHP Tutorial >Solution to Safe Alert: Request Error step 1/2 appearing in DedeCms, dedecmssafe_PHP tutorial
dedecms security warning: Safe Alert: Request Error step 2! I don’t know if anyone has noticed this phenomenon. Only since Dedecms officially announced that the previous version had serious vulnerabilities, the DedeCMS-V5.7-UTF8-SP1-Full version is now used when imitating the website. There is no way. The previous version was used well. , and now there is a vulnerability again, so I have to change to the latest version. There is actually a similar situation when Safe Alert: Request Error step 2 appears, such as: Safe Alert: Request Error step 1/2 appears on DedeCms! These situations are all caused by the anti-injection code of dede security detection. Of course, the reasons for this situation vary, and generally it is caused by a piece of code on the Internet. This is also the first time I encountered this situation. I quickly searched on Baidu and found two solutions:
1. Everyone uses different versions of the program. This problem may occur after upgrading. The upgraded version has an anti-injection function, so a security warning will appear. Among these anti-injection codes, once a code among "union|sleep|benchmark|load_file|outfile" appears on the web page, a security warning will appear. However, this problem cannot be completely solved at present, and we can only rely on manual code modification. The principle is that by modifying the anti-injection code, when prohibited characters appear on the web page, it will also pass the security detection. The method is: open dedesql.class.php under include to find the constructor, and change $this->safeCheck = true; on line 50 to $this->safeCheck = FALSE; The problem will be solved successfully.
2. Someone on the dede forum said that another method can be used to solve the problem of Safe Alert: Request Error step 1/2 when posting articles. The method is: modify the performance options in the DedeCms system parameters----Finally A cache form is changed to id (the system cache must be updated after modifying this variable). The problem I encountered is Safe Alert: Request Error step 2. This method cannot solve the problem, but for Safe Alert: Request Error step 1 /2! Whether the security warning has any effect, you can test it yourself.
Your statement is correct. Is it possible that there are other unsafe SQL statements on the page? If you really don’t know the reason, add $dsql->safeCheck = false; of course to the head of your file. is unsafe.
{ fputs(fopen($log_file,