Closed nathanlesage closed 3 years ago
@nathanlesage Thanks for your issue. The naming of the install.html
file is intentional. It's to help prevent "drive-by" installations where an external user visits the domain or subdomain at the same time that the installation files are available and potentially runs through the installation process accidentally or maliciously.
By having this small extra step of adding install.html
to the URL, it makes it more likely to be the intended action, as there's very little to no chance that install.html
will be loaded automatically when the domain or subdomain is accessed without a path.
I see the issue absolutely. However, I think chances are quite low that a drive-by installation might happen (nor that the install.html
would prevent anything, especially since servers by default spit out directory listings — all that malicious actors would have to do is actually to click the filename).
However, in order to make it really secure, one cool thing would be to generate a security code when api.php
is first accessed that is deposited on the server once install.html
is started, and which has to be entered into the web installer. Since people must upload the install.zip
to the server anyway, they will also be able to look into a file generated upon first opening install.html
and enter this code manually. Kind of a one-time password/CSRF-token.
I've seen that somewhere implemented, and it felt really secure. And that would definitely make the installation only accessible for the person having access to the server.
What do you think?
If you can remember and link us to the example of someone employing this one-time password method, that would be awesome, just so I can see how others have done it.
I know that the install.html
is by no means fool-proof, but it felt the best way to at least somewhat mitigate the issue, whilst still maintaining a simple process of installation. I want to avoid introducing more steps for people to do in order to install Winter, as more steps introduce extra complexity for casual users and increases the likelihood that they simply don't bother going through with the install.
The directory listing issue could probably be mitigated even further by simply including a blank index.html
with the install files, which would be removed on install.
What are your thoughts on that?
Yeah, an empty index.html would work.
@bennothommo I don't remember it, was quite a while back, but I found that Neos.io does this: https://docs.neos.io/cms/installation-development-setup/running-the-setup-tool
In the end, it would absolutely suffice to generate 32 chars of random string using Laravel's random string helper (https://laravel.com/docs/8.x/helpers#method-str-random) and drop that into a TXT-file.
From a usability perspective this would also be fine since people are very likely still logged in to the server when they start the installer. Opening a small text file and just Ctrl+A -> Ctrl+C -> Ctrl+V should be fairly easy.
In any case: I think having the one-time-password looks much more deliberate in preventing attacks. Having to manually type install.html
seems a little bit as if someone just forgot something, so I think users will not mind and actually think "Oh, I have to prove that I'm the right person to install this, that's a nice secure feature!". (Do I make sense…? It's the sociologist in me that's speaking)
@nathanlesage thanks for that. It definitely is an interesting take on the installation process.
I feel that, on balance, having to get people to type in a password every install is probably one step too far, especially for people who have to install a large number of sites. Requiring people to have to type install.html
at the end of their URLs is not a huge leap.
The install.html
addition also is preferable for a couple of more reasons:
install.php
, so this is not that much different.install.html
makes the file immediately identifiable as being part of the install process. If the installer didn't clean it up after finishing, for whatever reason, someone will be able to easily identify that file and remove it more so than an index.html
.index.html
for a holding page, if people wanted to install the site while everyone else sees a holding page until the installation is complete.It also would allow people to use their own index.html for a holding page, if people wanted to install the site while everyone else sees a holding page until the installation is complete.
That's actually a good point. There are definitely valuable arguments against my idea. I still think it might be nicer to have everything redirect, but then that's down to purely subjective preference.
EDIT: Yeah, I think I do see the reasoning. Closing the issue. Thank you all for the input and the ideas I didn't consider!
Happy to re-open if you think of anything else that might sway us back the other direction :)
Heya,
just tried out the web installer and technically it works flawlessly. There is one aesthetic improvement, though: It would be great if users were able to access the web installer by only visiting the domain itself, which could then redirect to the installer itself. Currently, if one doesn't append the
index.html
to the domain, Apache servers, for instance, deliver a directory listing.I see two options for this:
.htaccess
that simply redirects to theinstall.html
-fileinstall.html
toindex.html
so that it gets delivered by default by the web serverI think the second version is more universal and should (?) work on NGINX as well, but I don't know how nginx handles default documents.