nextcloud/lib/private/Setup.php

535 lines
16 KiB
PHP
Raw Normal View History

2011-04-17 02:45:05 +04:00
<?php
/**
2016-07-21 18:07:57 +03:00
* @copyright Copyright (c) 2016, ownCloud, Inc.
*
2015-03-26 13:44:34 +03:00
* @author Administrator <Administrator@WINDOWS-2012>
2016-05-26 20:56:05 +03:00
* @author Arthur Schiwon <blizzz@arthur-schiwon.de>
2015-03-26 13:44:34 +03:00
* @author Bart Visscher <bartv@thisnet.nl>
* @author Bernhard Posselt <dev@bernhard-posselt.com>
* @author Brice Maron <brice@bmaron.net>
2016-05-26 20:56:05 +03:00
* @author Christoph Wurst <christoph@owncloud.com>
2015-03-26 13:44:34 +03:00
* @author François Kubler <francois@kubler.org>
* @author Jakob Sack <mail@jakobsack.de>
2016-07-21 18:07:57 +03:00
* @author Joas Schilling <coding@schilljs.com>
2016-05-26 20:56:05 +03:00
* @author Lukas Reschke <lukas@statuscode.ch>
2015-03-26 13:44:34 +03:00
* @author Martin Mattel <martin.mattel@diemattels.at>
2016-01-12 17:02:16 +03:00
* @author Morris Jobke <hey@morrisjobke.de>
2016-07-21 19:13:36 +03:00
* @author Robin Appelman <robin@icewind.nl>
2016-07-21 18:07:57 +03:00
* @author Roeland Jago Douma <roeland@famdouma.nl>
2015-03-26 13:44:34 +03:00
* @author Sean Comeau <sean@ftlnetworks.ca>
* @author Serge Martin <edb@sigluy.net>
* @author Thomas Müller <thomas.mueller@tmit.eu>
* @author Vincent Petry <pvince81@owncloud.com>
*
* @license AGPL-3.0
*
* This code is free software: you can redistribute it and/or modify
* it under the terms of the GNU Affero General Public License, version 3,
* as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Affero General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public License, version 3,
* along with this program. If not, see <http://www.gnu.org/licenses/>
*
*/
2015-02-21 22:51:50 +03:00
namespace OC;
use bantu\IniGetWrapper\IniGetWrapper;
2015-02-21 22:51:50 +03:00
use Exception;
use OC\App\AppStore\Bundles\BundleFetcher;
use OCP\Defaults;
use OCP\IL10N;
use OCP\ILogger;
use OCP\Security\ISecureRandom;
2011-04-17 02:45:05 +04:00
2015-02-21 22:51:50 +03:00
class Setup {
/** @var SystemConfig */
protected $config;
/** @var IniGetWrapper */
protected $iniWrapper;
/** @var IL10N */
protected $l10n;
/** @var Defaults */
protected $defaults;
/** @var ILogger */
protected $logger;
/** @var ISecureRandom */
protected $random;
/**
* @param SystemConfig $config
* @param IniGetWrapper $iniWrapper
* @param IL10N $l10n
* @param Defaults $defaults
* @param ILogger $logger
* @param ISecureRandom $random
*/
public function __construct(SystemConfig $config,
IniGetWrapper $iniWrapper,
IL10N $l10n,
Defaults $defaults,
ILogger $logger,
ISecureRandom $random
) {
$this->config = $config;
$this->iniWrapper = $iniWrapper;
$this->l10n = $l10n;
$this->defaults = $defaults;
$this->logger = $logger;
$this->random = $random;
}
static $dbSetupClasses = [
'mysql' => \OC\Setup\MySQL::class,
'pgsql' => \OC\Setup\PostgreSQL::class,
'oci' => \OC\Setup\OCI::class,
'sqlite' => \OC\Setup\Sqlite::class,
'sqlite3' => \OC\Setup\Sqlite::class,
];
2013-02-09 22:23:36 +04:00
/**
* Wrapper around the "class_exists" PHP function to be able to mock it
* @param string $name
* @return bool
*/
protected function class_exists($name) {
return class_exists($name);
}
/**
* Wrapper around the "is_callable" PHP function to be able to mock it
* @param string $name
* @return bool
*/
protected function is_callable($name) {
return is_callable($name);
}
/**
* Wrapper around \PDO::getAvailableDrivers
*
* @return array
*/
protected function getAvailableDbDriversForPdo() {
return \PDO::getAvailableDrivers();
}
/**
* Get the available and supported databases of this instance
*
2015-03-11 17:47:24 +03:00
* @param bool $allowAllDatabases
* @return array
2015-03-11 17:47:24 +03:00
* @throws Exception
*/
2015-03-11 17:47:24 +03:00
public function getSupportedDatabases($allowAllDatabases = false) {
$availableDatabases = array(
'sqlite' => array(
'type' => 'pdo',
'call' => 'sqlite',
'name' => 'SQLite'
),
'mysql' => array(
'type' => 'pdo',
'call' => 'mysql',
'name' => 'MySQL/MariaDB'
),
'pgsql' => array(
'type' => 'pdo',
'call' => 'pgsql',
'name' => 'PostgreSQL'
),
'oci' => array(
'type' => 'function',
'call' => 'oci_connect',
'name' => 'Oracle'
)
);
2015-03-11 17:47:24 +03:00
if ($allowAllDatabases) {
$configuredDatabases = array_keys($availableDatabases);
} else {
$configuredDatabases = $this->config->getValue('supportedDatabases',
2015-03-11 17:47:24 +03:00
array('sqlite', 'mysql', 'pgsql'));
}
if(!is_array($configuredDatabases)) {
throw new Exception('Supported databases are not properly configured.');
}
$supportedDatabases = array();
foreach($configuredDatabases as $database) {
if(array_key_exists($database, $availableDatabases)) {
$working = false;
$type = $availableDatabases[$database]['type'];
$call = $availableDatabases[$database]['call'];
if ($type === 'function') {
$working = $this->is_callable($call);
} elseif($type === 'pdo') {
$working = in_array($call, $this->getAvailableDbDriversForPdo(), TRUE);
}
if($working) {
$supportedDatabases[$database] = $availableDatabases[$database]['name'];
}
}
}
return $supportedDatabases;
}
/**
* Gathers system information like database type and does
* a few system checks.
*
* @return array of system info, including an "errors" value
* in case of errors/warnings
*/
2015-03-11 17:47:24 +03:00
public function getSystemInfo($allowAllDatabases = false) {
$databases = $this->getSupportedDatabases($allowAllDatabases);
$dataDir = $this->config->getValue('datadirectory', \OC::$SERVERROOT.'/data');
$errors = array();
// Create data directory to test whether the .htaccess works
// Notice that this is not necessarily the same data directory as the one
// that will effectively be used.
if(!file_exists($dataDir)) {
@mkdir($dataDir);
}
$htAccessWorking = true;
if (is_dir($dataDir) && is_writable($dataDir)) {
// Protect data directory here, so we can test if the protection is working
\OC\Setup::protectDataDirectory();
try {
$util = new \OC_Util();
$htAccessWorking = $util->isHtaccessWorking(\OC::$server->getConfig());
} catch (\OC\HintException $e) {
$errors[] = array(
'error' => $e->getMessage(),
'hint' => $e->getHint()
);
$htAccessWorking = false;
}
}
if (\OC_Util::runningOnMac()) {
$errors[] = array(
'error' => $this->l10n->t(
'Mac OS X is not supported and %s will not work properly on this platform. ' .
'Use it at your own risk! ',
$this->defaults->getName()
),
'hint' => $this->l10n->t('For the best results, please consider using a GNU/Linux server instead.')
);
}
if($this->iniWrapper->getString('open_basedir') !== '' && PHP_INT_SIZE === 4) {
$errors[] = array(
'error' => $this->l10n->t(
'It seems that this %s instance is running on a 32-bit PHP environment and the open_basedir has been configured in php.ini. ' .
'This will lead to problems with files over 4 GB and is highly discouraged.',
$this->defaults->getName()
),
'hint' => $this->l10n->t('Please remove the open_basedir setting within your php.ini or switch to 64-bit PHP.')
);
}
return array(
'hasSQLite' => isset($databases['sqlite']),
'hasMySQL' => isset($databases['mysql']),
'hasPostgreSQL' => isset($databases['pgsql']),
'hasOracle' => isset($databases['oci']),
'databases' => $databases,
'directory' => $dataDir,
'htaccessWorking' => $htAccessWorking,
'errors' => $errors,
);
}
/**
* @param $options
* @return array
*/
public function install($options) {
$l = $this->l10n;
2013-02-09 22:23:36 +04:00
$error = array();
2014-10-27 21:53:12 +03:00
$dbType = $options['dbtype'];
2012-08-29 10:38:33 +04:00
if(empty($options['adminlogin'])) {
2013-02-09 22:23:36 +04:00
$error[] = $l->t('Set an admin username.');
}
if(empty($options['adminpass'])) {
2013-02-09 22:23:36 +04:00
$error[] = $l->t('Set an admin password.');
}
if(empty($options['directory'])) {
2015-02-21 22:51:50 +03:00
$options['directory'] = \OC::$SERVERROOT."/data";
}
2011-08-07 23:06:53 +04:00
2014-10-27 21:53:12 +03:00
if (!isset(self::$dbSetupClasses[$dbType])) {
$dbType = 'sqlite';
2012-10-27 00:46:12 +04:00
}
$username = htmlspecialchars_decode($options['adminlogin']);
$password = htmlspecialchars_decode($options['adminpass']);
2014-10-27 21:53:12 +03:00
$dataDir = htmlspecialchars_decode($options['directory']);
2014-10-27 21:53:12 +03:00
$class = self::$dbSetupClasses[$dbType];
/** @var \OC\Setup\AbstractDatabase $dbSetup */
$dbSetup = new $class($l, 'db_structure.xml', $this->config,
$this->logger, $this->random);
2013-06-27 22:19:51 +04:00
$error = array_merge($error, $dbSetup->validate($options));
2012-10-27 00:46:12 +04:00
// validate the data directory
if (
2014-10-27 21:53:12 +03:00
(!is_dir($dataDir) and !mkdir($dataDir)) or
!is_writable($dataDir)
) {
2014-10-27 21:53:12 +03:00
$error[] = $l->t("Can't create or write into the data directory %s", array($dataDir));
}
if(count($error) != 0) {
return $error;
2012-10-27 00:46:12 +04:00
}
$request = \OC::$server->getRequest();
//no errors, good
if(isset($options['trusted_domains'])
&& is_array($options['trusted_domains'])) {
$trustedDomains = $options['trusted_domains'];
} else {
$trustedDomains = [$request->getInsecureServerHost()];
}
2012-10-27 00:46:12 +04:00
2014-10-27 21:53:12 +03:00
//use sqlite3 when available, otherwise sqlite2 will be used.
if($dbType=='sqlite' and class_exists('SQLite3')) {
$dbType='sqlite3';
2011-04-17 02:45:05 +04:00
}
//generate a random salt that is used to salt the local user passwords
$salt = $this->random->generate(30);
// generate a secret
$secret = $this->random->generate(48);
2011-05-07 00:50:18 +04:00
//write the config file
$this->config->setValues([
'passwordsalt' => $salt,
'secret' => $secret,
'trusted_domains' => $trustedDomains,
'datadirectory' => $dataDir,
2015-02-21 22:51:50 +03:00
'overwrite.cli.url' => $request->getServerProtocol() . '://' . $request->getInsecureServerHost() . \OC::$WEBROOT,
'dbtype' => $dbType,
'version' => implode('.', \OCP\Util::getVersion()),
]);
try {
2013-06-27 22:19:51 +04:00
$dbSetup->initialize($options);
$dbSetup->setupDatabase($username);
// apply necessary migrations
$dbSetup->runMigrations();
} catch (\OC\DatabaseSetupException $e) {
$error[] = array(
'error' => $e->getMessage(),
'hint' => $e->getHint()
);
return($error);
} catch (Exception $e) {
$error[] = array(
'error' => 'Error while trying to create admin user: ' . $e->getMessage(),
'hint' => ''
);
return($error);
}
2012-10-27 00:46:12 +04:00
//create the user and group
2015-02-21 22:51:50 +03:00
$user = null;
try {
2015-02-21 22:51:50 +03:00
$user = \OC::$server->getUserManager()->createUser($username, $password);
if (!$user) {
$error[] = "User <$username> could not be created.";
}
2014-10-27 21:53:12 +03:00
} catch(Exception $exception) {
$error[] = $exception->getMessage();
2012-10-27 00:46:12 +04:00
}
if(count($error) == 0) {
2015-02-21 22:51:50 +03:00
$config = \OC::$server->getConfig();
$config->setAppValue('core', 'installedat', microtime(true));
$config->setAppValue('core', 'lastupdatedat', microtime(true));
$config->setAppValue('core', 'vendor', $this->getVendor());
2012-10-27 00:46:12 +04:00
2015-02-21 22:51:50 +03:00
$group =\OC::$server->getGroupManager()->createGroup('admin');
$group->addUser($user);
2016-04-27 13:01:13 +03:00
// Install shipped apps and specified app bundles
2016-04-28 16:15:34 +03:00
Installer::installShippedApps();
$installer = new Installer(
\OC::$server->getAppFetcher(),
\OC::$server->getHTTPClientService(),
\OC::$server->getTempManager(),
\OC::$server->getLogger(),
\OC::$server->getConfig()
);
$bundleFetcher = new BundleFetcher(\OC::$server->getL10N('lib'));
$defaultInstallationBundles = $bundleFetcher->getDefaultInstallationBundle();
foreach($defaultInstallationBundles as $bundle) {
try {
$installer->installAppBundle($bundle);
} catch (Exception $e) {}
}
2013-02-09 22:23:36 +04:00
// create empty file in data dir, so we can later find
// out that this is indeed an ownCloud data directory
2015-02-21 22:51:50 +03:00
file_put_contents($config->getSystemValue('datadirectory', \OC::$SERVERROOT.'/data').'/.ocdata', '');
// Update .htaccess files
Setup::updateHtaccess();
Setup::protectDataDirectory();
self::installBackgroundJobs();
//and we are done
2015-02-21 22:51:50 +03:00
$config->setSystemValue('installed', true);
// Create a session token for the newly created user
// The token provider requires a working db, so it's not injected on setup
/* @var $userSession User\Session */
$userSession = \OC::$server->getUserSession();
$defaultTokenProvider = \OC::$server->query('OC\Authentication\Token\DefaultTokenProvider');
$userSession->setTokenProvider($defaultTokenProvider);
$userSession->login($username, $password);
$userSession->createSessionToken($request, $userSession->getUser()->getUID(), $username, $password);
}
2012-10-27 00:46:12 +04:00
return $error;
}
2013-02-12 04:05:47 +04:00
public static function installBackgroundJobs() {
\OC::$server->getJobList()->add('\OC\Authentication\Token\DefaultTokenCleanupJob');
}
/**
* @return string Absolute path to htaccess
*/
private function pathToHtaccess() {
2015-02-21 22:51:50 +03:00
return \OC::$SERVERROOT.'/.htaccess';
}
/**
* Append the correct ErrorDocument path for Apache hosts
2016-09-13 11:50:58 +03:00
* @return bool True when success, False otherwise
*/
public static function updateHtaccess() {
$config = \OC::$server->getSystemConfig();
// For CLI read the value from overwrite.cli.url
2015-12-08 10:17:04 +03:00
if(\OC::$CLI) {
$webRoot = $config->getValue('overwrite.cli.url', '');
if($webRoot === '') {
2016-09-13 11:50:58 +03:00
return false;
}
$webRoot = parse_url($webRoot, PHP_URL_PATH);
$webRoot = rtrim($webRoot, '/');
} else {
$webRoot = !empty(\OC::$WEBROOT) ? \OC::$WEBROOT : '/';
2015-12-08 10:17:04 +03:00
}
$setupHelper = new \OC\Setup($config, \OC::$server->getIniWrapper(),
\OC::$server->getL10N('lib'), \OC::$server->query(Defaults::class), \OC::$server->getLogger(),
\OC::$server->getSecureRandom());
$htaccessContent = file_get_contents($setupHelper->pathToHtaccess());
$content = "#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####\n";
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
$htaccessContent = explode($content, $htaccessContent, 2)[0];
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
//custom 403 error page
$content.= "\nErrorDocument 403 ".$webRoot."/core/templates/403.php";
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
//custom 404 error page
$content.= "\nErrorDocument 404 ".$webRoot."/core/templates/404.php";
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
// Add rewrite rules if the RewriteBase is configured
$rewriteBase = $config->getValue('htaccess.RewriteBase', '');
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
if($rewriteBase !== '') {
$content .= "\n<IfModule mod_rewrite.c>";
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
$content .= "\n Options -MultiViews";
$content .= "\n RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]";
$content .= "\n RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !\\.(css|js|svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !core/img/favicon.ico$";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !core/img/manifest.json$";
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/remote.php";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/public.php";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/cron.php";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/core/ajax/update.php";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/status.php";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/ocs/v1.php";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/ocs/v2.php";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/robots.txt";
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/updater/";
$content .= "\n RewriteCond %{REQUEST_FILENAME} !/ocs-provider/";
$content .= "\n RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*";
$content .= "\n RewriteRule . index.php [PT,E=PATH_INFO:$1]";
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
$content .= "\n RewriteBase " . $rewriteBase;
$content .= "\n <IfModule mod_env.c>";
$content .= "\n SetEnv front_controller_active true";
$content .= "\n <IfModule mod_dir.c>";
$content .= "\n DirectorySlash off";
$content .= "\n </IfModule>";
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
$content .= "\n </IfModule>";
$content .= "\n</IfModule>";
}
Do not automatically try to enable index.php-less URLs (#24539) The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
2016-05-12 10:43:26 +03:00
if ($content !== '') {
//suppress errors in case we don't have permissions for it
return (bool) @file_put_contents($setupHelper->pathToHtaccess(), $htaccessContent.$content . "\n");
}
return false;
}
public static function protectDataDirectory() {
//Require all denied
$now = date('Y-m-d H:i:s');
2017-02-24 14:13:26 +03:00
$content = "# Generated by Nextcloud on $now\n";
$content.= "# line below if for Apache 2.4\n";
$content.= "<ifModule mod_authz_core.c>\n";
$content.= "Require all denied\n";
$content.= "</ifModule>\n\n";
$content.= "# line below if for Apache 2.2\n";
$content.= "<ifModule !mod_authz_core.c>\n";
$content.= "deny from all\n";
$content.= "Satisfy All\n";
$content.= "</ifModule>\n\n";
$content.= "# section for Apache 2.2 and 2.4\n";
$content.= "<ifModule mod_autoindex.c>\n";
$content.= "IndexIgnore *\n";
$content.= "</ifModule>\n";
$baseDir = \OC::$server->getConfig()->getSystemValue('datadirectory', \OC::$SERVERROOT . '/data');
file_put_contents($baseDir . '/.htaccess', $content);
file_put_contents($baseDir . '/index.html', '');
}
/**
* Return vendor from which this version was published
*
* @return string Get the vendor
*
* Copy of \OC\Updater::getVendor()
*/
private function getVendor() {
// this should really be a JSON file
require \OC::$SERVERROOT . '/version.php';
/** @var string $vendor */
return (string) $vendor;
}
2011-04-17 02:45:05 +04:00
}