Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split frontend- and backend files #656

Closed
samimussbach opened this issue Apr 14, 2009 · 11 comments
Closed

Split frontend- and backend files #656

samimussbach opened this issue Apr 14, 2009 · 11 comments
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Milestone

Comments

@samimussbach
Copy link

It would be great to have an easy possibility to hide the files that are not needed to be public from the view and place them somewhere outside the DocumentRoot of the webserver.
This is kind of best practice and I would appreciate this highly! The way it is at the moment is way easier to install, but also way more insecure. Perhaps you could provide some alternative way for paranoid sysadmins :-)

Thanks for your effort

@anonymous-matomo-user
Copy link

I totally agree!
Using the zend proposed tree can let piwik easy to install and more secure at the same time :

http://framework.zend.com/docs/quickstart/set-up-the-project-structure

@samimussbach
Copy link
Author

Replying to [klando](comment:1):

yes, but be careful that using this commonly used but static structure may not fit the needs of every project. I would suggest a config-variable of the path to the “rest” (say non public part) of piwik. This may be after the zend suggestion by default, but should be easy to change, if my directory is not named library but Libraries and I do not want to change this in my basic project.

@anonymous-matomo-user
Copy link

Replying to [kaspar](comment:2):

> Replying to [klando](comment:1):
>
> yes, but be careful that using this commonly used but static structure may not fit the needs of every project. I would suggest a config-variable of the path to the “rest” (say non public part) of piwik. This may be after the zend suggestion by default, but should be easy to change, if my directory is not named library but Libraries and I do not want to change this in my basic project.

This is adjusted in the bootsrap file (from memory, I didn’t check carefully), I wanted to point the ‘public/’ versus the other dirs of the app.

@robocoder
Copy link
Contributor

I also like the idea of separation as it would not require web server-specific .htaccess files (which also impact the web server’s performance). However, I don’t think the aforementioned ZF project structure would be an easy (or even desirable) re-fit for Piwik.

The good news is index.php and piwik.php already perform the bootstrapping and funnel-access-through functionality needed to make much of this separation possible.

The head-scratcher is resolving paths so that Piwik can find itself (e.g., plugins are problematic because of mixed content in each plugin folder).

On top of this:
- we’ll need a build script to package releases differently. (This would be preferable to wholesale file moving in SVN, and still provide convenience to developers.)
- the implication is that Piwik unzipped, won’t run out-of-the-box — the user has to create a new (or copy an existing) bootstrap configuration file specific to his/her environment. A more complicated install means more documentation and user support.
- static content (images, javascript, stylesheets) should remain in ‘public’ so that it can be served directly.

@robocoder
Copy link
Contributor

- auto-update

@mattab
Copy link
Member

mattab commented Apr 15, 2009

because of the reasons you mention vipsoft, I’d mark this “wontfix” as
- we are careful not to have any public file in Piwik that would contain or display sensitive information (all files are classes or if they’re scripts, they contain the required permission check to ensure only some users can execute them eg. generateVisits script)
- having this sort of installation would mean: more support, documentation, complexity.. for no added security.

@robocoder
Copy link
Contributor

If you don't mind losing one-click updates, I think this is doable:

  • copy the core, libs, plugins, config, and tmp folders to a location outside of the piwik document root
  • run "find" to remove .php and .tpl files in those folders still in the document root
  • in index.php and piwik.php, manually set PIWIK_INCLUDE_PATH to point to the hidden(?) folder

Disclaimer: untested; use a snapshot from svn (or wait for 0.4.2)

We probably won't change the build/release script, but if you come up with a patch for the Updater, we'll consider it. (You might start with defining PIWIK_DOCUMENT_ROOT, and reading a bootstrap.ini.php file, if present, to override PIWIK_INCLUDE_PATH.)

@robocoder
Copy link
Contributor

(In [1341]) refs #886, #656, #8585 - add PIWIK_DOCUMENT_ROOT and optional inclusion of bootstrap.php

@robocoder
Copy link
Contributor

(In [1342]) refs #656 - add $excludePhp flag to Piwik::copyRecursive() to exclude PHP files copied to PIWIK_DOCUMENT_ROOT

@robocoder
Copy link
Contributor

The last two check-ins should satisfy the requirement of being able to relocate ("hide") backend files outside of the document root.

The task of splitting front- and backend files is described in comment:8.

@robocoder
Copy link
Contributor

p.s. a copy of the root directory files (bootstrap.php, index.php, and piwik.php) would have to exist in both PIWIK_DOCUMENT_ROOT and PIWIK_INCLUDE_PATH directories for things tests/all_tests.php and misc/generateVisits.php to work.

@samimussbach samimussbach added this to the Piwik 0.4.3 milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
Development

No branches or pull requests

4 participants