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
[fix] Do not create .htaccess with Nginx #226
base: master
Are you sure you want to change the base?
Conversation
It should do that automatically. That's the whole purpose of this tool. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW: Now you did not revert any changes from master… 👍
if (!@mkdir(self::$_path, 0700)) { | ||
throw new Exception('unable to create directory ' . self::$_path, 10); | ||
if (property_exists($data->meta, 'webserver') && $data->meta->webserver && $this->_conf->getKey('webserver') == "Apache") { | ||
// Create storage directory if it does not exist. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK the storage dir (data dir) is not connected to the webserver you use. It should also be done when using nginx…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the condition
lib/Configuration.php
Outdated
@@ -54,6 +54,7 @@ class Configuration | |||
'icon' => 'identicon', | |||
'cspheader' => 'default-src \'none\'; manifest-src \'self\'; connect-src *; script-src \'self\'; style-src \'self\'; font-src \'self\'; img-src \'self\' data:; referrer no-referrer; sandbox allow-same-origin allow-scripts allow-forms allow-popups', | |||
'zerobincompatibility' => false, | |||
'webserver' => 'Apache', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can fix the indentation afterwards (PHP-CS does it for us), but if you want, you can of course bring it in a nicely, order "table style"…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for changing it.
cfg/conf.ini.sample
Outdated
@@ -75,6 +75,10 @@ languageselection = false | |||
; sha256 in HMAC for the deletion token | |||
zerobincompatibility = false | |||
|
|||
; allows you to specify the name of the web server you are using to use ParseBin. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: "ParseBin"
Also a funny name, but was not our favourite… 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum ... Sorry again !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
He, this was actually a funny one… 😄
cfg/conf.ini.sample
Outdated
@@ -75,6 +75,10 @@ languageselection = false | |||
; sha256 in HMAC for the deletion token | |||
zerobincompatibility = false | |||
|
|||
; allows you to specify the name of the web server you are using to use ParseBin. | |||
; if you use Nginx, decommente and add nginx. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"decommente" does not exist, please use "uncomment" instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My french !
if (!is_dir(self::$_path)) { | ||
if (!@mkdir(self::$_path, 0700)) { | ||
throw new Exception('unable to create directory ' . self::$_path, 10); | ||
if (property_exists($data->meta, 'webserver') && $data->meta->webserver && $this->_conf->getKey('webserver') == "Apache") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This now does not check the web server anymore as far as I see… It just assumes "Apache by default" and only if the admin changes the settings in the options it assumes "any other web server".
However, I'd rather like to see this behaviour:
- By default the config is either empty or set to "auto" or so, which auto-selects/detects the correct server based on env. variables e.g.
- The server admin can override this behaviour by changing the option in the settings, so can e.g. force Apache or disallow it. This could be useful when the automatic detection does not work…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand how you want this to happen, i will see what I can do.
But I do not know if it's a best way ? I try.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you have a better idea, just explain it…
Comments are there to discuss things. IMHO "autodetection" as it was (partly) implemented in your first PR is a good idea.
throw new Exception('unable to write to file ' . $file, 11); | ||
$file = self::$_path . DIRECTORY_SEPARATOR . '.htaccess'; | ||
if (!is_file($file)) { | ||
$writtenBytes = @file_put_contents( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be awesome if you could also detect the server version of Apache as Apache <2.4 needed a different format. So if you want to solve #194 (comment).
Thanks for the fixes. Still TODO:
|
Thanks for working on this! The logic of the WebServer class looks quite clean, with my only suggestion being to maybe change the fixed version regex compare to the version_compare one, so it works with future apache versions, too. Note that .htaccess files may need to be created in various places, not just in the web root, so there should be a mechanism to pass the absolute path into the The name That aside, I can write the unit tests for this before merging it, if you want. |
Yes, is a good idea for change name for this function. restrictAccessTo() is a good name for me. I also think that I have written badly name of my WebServer function. Would it be more logical to write it ServerWeb as for ServerSalt? if that's okay, I'll rename the file too. I would like to write the tests, but I can't get them to work properly. I want you to write them;) |
Okaydoky on the tests, WebServer as class name is fine by me, as we usually do call these objects "web servers". ;-) PS: I am now starting to reconsider renaming ServerSalt to simply Salt, since that class is now used to generate the paste salts, too, and not only for the instance wide salt. |
i will add $path for a restrictAccessTo() function, but for the moment, i don't know how to added neatly into lib/Model/Paste.php |
@magikcypress Any chance you can have a look at finishing the PR? |
I don't know, i haven't a lot anytime for patch this PR, sorry. In fact, i don't know how get a variable $_path in my code for to be used a WebServer class anywhere ? |
@magikcypress Are you still interested in completing this? If not, that's no problem, just add a notice, so I know what the current status of this PR is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm this only creates the htaccess file is you explicitly configure PB and state in the config file that you use Apache,
This PR is abanded anyway, but I also would not merge it as per today I guess, because:
- that automatic
.htaccess
is a security feature, mostly intended for sysadmins that are quite new to webservers or just forget stuff like doing any hardening steps. - as such, it is an "automatic breach prevention feature", because if you do not properly secure the server otherwise, it will do it by itself
This is not only theoretical. Back in the days we actually had a vulnerability similar to that and decided to publish a "fixed" version that essentially improved our security procedures by switching to .php
files there.
Well anyway… you can read that there…, but the point is: This is one layer of defense against insecure misconfigured servers. And if we can do sth. against that (within constrains), IMHO, we should.
So what?
So given this all applies, I think this change here would decrease the security of the whole system, because this system here is especially aimed at users, who may not even take a look into the config file.
Note that most other stuff of PB may work more or less out of the box (correct me if I am wrong), so they may actually forget or (deliberately) just not see any reason to adjust the config or that single server name thing. I mean, why should they?
If that is the case, they will not adjust it, anyway run it on Apache and have a potentially unprotected or less protected instance.
Advantage
So to way that against the advantage of this PR that is just…
- to have a clean file system without that file?
I mean that file is just a file, it may disturb, but really, if that is the only disadvantage of not merging this…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While writing (rubber duck says hi) it just came to mind that one single change that I do not really see here would probably fix all my concerns:
- Make the config (/our defaults) for that value default to "Apache", i.e./and thus to creating that file.
Because then we have the out-of-the-box (OOTB) security while for nginx or so the file does not need to be generated if people do not want that and e.g. if it may cause deployment issues.
So that is why I leave that PR open.
I use editorConfig but I'm not sure for indentation ?
added by @rugk:
replaces PR #223
fixes #222