-
-
Notifications
You must be signed in to change notification settings - Fork 662
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
Flarum support #3242
Flarum support #3242
Conversation
ohh nice. Thank you for this :) <3 Flarum is really nice |
Just ran Prettier to do the linting / code clean up I assume we need an Nginx template for Flarum |
Yes, when currently run there is a suggested .nginx.conf file that appears in the install root per Flarum's suggestion. Not quite sure how/what to integrate with (which existing Nginx template should be used). Help wanted. I believe it will function without; but poses security risk as |
parent::setup($options); | ||
$result = null; | ||
|
||
// Move public folder content (https://docs.flarum.org/install/#customizing-paths) |
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.
From a Flarum POV, this type of install should be avoided if at all possible.
As mentioned in a comment, we have an nginx config available which can handle path rewriting automatically so this shouldn't be needed.
Good points, I will update the logo. Thank you for your feedback!
Can you please clarify “should be avoided” as I’m unable to find a related sentiment in Flarum’s official install documentation. In contrast, Flarum
currently, **specifically** states, “…with something like public_html or htdocs), you can set up Flarum without the public directory…”. (You may wish to submit a pull request to Flarum’s documentation to correct this?).
We do indeed have a “public_html” folder present; although I would agree with their assessment “public directory…is a security best practice”, this Quick Installer does accommodate the “…wish to host Flarum in a subdirectory” option which again, does away with the public folder and negates it’s necessity per their own documentation.
For example, often times users may wish to create a WordPress or other installation in root, and use Quick Installer to create a forum in a subdirectory.
According to the documentation, .htaccess rules are specific for Apache and is a hard requirement to “…protect sensitive resources….” (per Flarum’s
documentation). While it is true that Hestia users are leveraging Nginx in a reverse proxy capacity; I would still err with the default, to include .htaccess restrictions (even if redundant). This may become especially true of when users mix installations (as mentioned with WordPress in root and Flarum in a subfolder); which Nginx rules apply?
Perhaps @jaapmarcus can clarify as I’m not understanding how Hestia’s Quick Installer accommodates multiple installations in a single web domain. In my Hestia v1.6.1, multi-PHP, Nginx+Apache, I am not seeing the WordPress.stpl being utilized in a default Quick Install App in a web domain’s root, and again, how it is resolved when doing another Quick
Install App of Flarum in a subfolder. Is there a location I can validate this? (Ie /etc/php/8.1/… pool or conf …?) Should I see multiple nginx.conf_* files in the user’s own conf/web/nginx folder? (I am currently not but maybe wrong?).
…On Sun, Feb 5, 2023 at 1:26 PM David Wheatley ***@***.***> wrote:
***@***.**** requested changes on this pull request.
------------------------------
In web/src/app/WebApp/Installers/Flarum/FlarumSetup.php
<#3242 (comment)>:
> + }
+ }
+ $tmp = $this->saveTempFile(implode("\r\n", $result->raw));
+ if (!$this->appcontext->runUser("v-move-fs-file", [$tmp, $file], $result)) {
+ throw new \Exception("Error updating file in: " . $tmp . " " . $result->text);
+ }
+ return $result;
+ }
+
+ public function install(array $options = null): bool {
+ parent::setAppDirInstall($options["install_directory"]);
+ parent::install($options);
+ parent::setup($options);
+ $result = null;
+
+ // Move public folder content (https://docs.flarum.org/install/#customizing-paths)
From a Flarum POV, this type of install should be avoided if at all
possible.
As mentioned in a comment, we have an nginx config available which can
handle path rewriting automatically so this shouldn't be needed.
------------------------------
In web/src/app/WebApp/Installers/Flarum/FlarumSetup.php
<#3242 (comment)>:
> @@ -0,0 +1,211 @@
+<?php
+namespace Hestia\WebApp\Installers\Flarum;
+
+use Hestia\System\Util;
+use Hestia\WebApp\Installers\BaseSetup as BaseSetup;
+
+class FlarumSetup extends BaseSetup {
+ protected $appInfo = [
+ "name" => "Flarum",
+ "group" => "forum",
+ "enabled" => true,
+ "version" => "latest",
+ "thumbnail" => "fl-thumb.png",
Could we use one of our official branding images here rather than
modifying an older version of the logo?
I've attached two options below.
[image: symbol name]
<https://user-images.githubusercontent.com/7406822/216846944-ee20834d-9c27-4ebf-86b6-2f45151d6334.svg>
[image: on gradient orange]
<https://user-images.githubusercontent.com/7406822/216846941-6b7ad2ca-ee1f-46e8-b873-ecb54f443d2b.svg>
—
Reply to this email directly, view it on GitHub
<#3242 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3EBZYNDOPTDXTD3CGTGDWWALJ5ANCNFSM6AAAAAAUPMP25Q>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
The idea of subdirectory installs is specifically that — for subdirectories (e.g., example.com/forum) OR if it's physically impossible for one to control the web root. It's meant as a backup if the normal method doesn't work. If the normal method can work here (e.g., use that if a subdir is not desired, otherwise the subdir install), it should be preferred. I can't stop you from using it this way, though. |
For Nginx only setup it is almost impractical. It doesn't even work for Wordpress. Unless you have a separate template working for it. Yes that is one of the downsides of Nginx setup.. |
I do have Nginx rules for WordPress that do work, for both permalinks and multisite (subfolder) mode. I can share those in a separate thread. Probably be best to utilize the default include for nginx.conf_* feature for these as it can allow Hestia to accommodate more than one set of Nginx configurations. |
Impossible to delete for the normal user unless he deletes the web domain first. That is a major downsite |
Ahh, yes... that is a definite problem. Sounds like we could use a UI to manage such conf files (disable or delete checkbox list). I hadn't thought of that. I may have to prototype that. |
It may cause major security if it is done by the "user" and can directly control them. For example: https://huntr.dev/bounties/357c0390-631c-4684-b6e1-a6d8b2453d66/ |
Noted. However, that is for an arbitrary input field that definitely needs validation. A "disable" or "delete" option on the other hand, furnishes the user with the ability to remove (or rename/move to disable folder) a nginx.conf_* file, but not alter its content (to introduce a syntax or other crash). |
Merge with latest main
Removes pesky "You are running phpPgAdmin without session security." warning and accommodates CSRF security measures
Removes pesky "You are running phpPgAdmin without session security." warning and accommodates CSRF security measures
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 is still lacking support for Nginx only setups
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.
Seems good to me from a Flarum perspective!
This reverts commit b0fbee3.
A Quick Install App for Hestia Control Panel that allows you to easily install Flarum, a modern, fast, open source, website forum software.