In the Project settings → Design section of my site, the “Invisible spam protection (simple)” design mode is enabled. However, on the website https://oe-it.ru/, a visible CAPTCHA is being displayed.
Please correct this incorrect behavior.
The page I need help with: [log in to see the link]
Can you click the ‘Save’ button in the design settings (Project settings → Design) in mosparo once? It looks like the change to invisible mode was not stored correctly by mosparo.
I configured the mosparo service for the network of sites, and everything was working correctly. On Friday, we updated mosparo, and after that, the CAPTCHA became visibly displayed on all projects (sites).
I tried your suggested solution, but unfortunately, it didn’t help.
I configured the mosparo service for the network of sites, and everything was working correctly. On Friday, we updated mosparo, and after that, the CAPTCHA became visibly displayed on all projects (sites). I tried your suggested solution, but unfortunately, it didn’t help.
Can you switch to visible mode once, then back to invisible mode? Please click the save button after changing the mode to ensure that the settings are stored correctly.
An update of mosparo should not cause such a problem, of course. I will have to investigate what went wrong as soon as we find the solution to your problem.
Thank you for the quick replies and your attention. — I’ve saved the visible mode. — I’ve saved the invisible mode. — I’ve tried changing the placement of the tag in the contact form.
The form on the website (Contact Form 7) still displays the CAPTCHA.
Thank you very much for your feedback and all the details.
The last problem (that the form is submitted as soon as you click the mosparo box) is understandable, because mosparo thinks it is in invisible mode. In invisible mode, after validating the form, mosparo should submit it. If you switch to the visible mode, you should not have that problem.
The problem is – of course – that the mosparo box is still visible. This is because the correct CSS file is not available in mosparo. The CSS file is generated when you change any design-related setting (by switching modes or clicking the save button). But since you still don’t have the file, it is probably a problem with writing the file on your web server.
Can you have a look at the directory “public/resources/” inside your mosparo installation? There should be a file called “mappings.php”. Does that file exist? If yes, do you see a folder called “b0e48e05-e8d2-4496-8928-cec12a2af2c4”?
There is no such file. Even the /public/resources directory is not on the disk. There are only build and bundles (as in .a zip file mosparo-stable-v1.4.7.zip ).
I’ll explain. In the installation directory, all files and directories (except /config and /var) are not writable. Is this wrong? There are no errors related to this in the logs.
P.S. When I changed the rights to /public, the error disappeared. An idle question: is it worth creating such resources in the /var directory?
Thank you very much for your answer and the details.
You can set everything to read-only except the following paths:
config/env.mosparo.php
var/
public/resources
If you want to use the frontend update functionality, you also need a directory called “public/update-log” that must be writeable. But I guess you use the CLI or a different update process since you set everything to read-only.
I’m sorry for the trouble. I saw that we do not highlight that anywhere in the documentation (at least where I looked now). We’ll update the documentation to point that out correctly. Additionally, we’ll add them to the ZIP file in the future with a hint that they should be writable (since you don’t see them right now, which creates even more problems). We also need to add error reporting in the interface when the CSS cache storage fails.
After you made the directory (public/resources) writeable, you need to save the design settings once more, and then you should see the files, and it should work as expected.
The idea is that you only expose the “public/” directory to the internet by setting the document root of your virtual host to the public directory.
Because of this, all publicly available files must be exposed to the internet, so they must be in the public directory.
We could put them in the var directory, but then we would have to deliver them via a PHP request, which is slower than direct file access by the web server.
So yes, technically, you’re right, such a file would be better placed in var. But from the security and performance perspective, the public directory is the right place to put it.
You can set everything to read-only except the following paths:
config/env.mosparo.php
This is not an entirely true statement. You don’t need write permissions on the file. config/env.mosparo.php , and to the config/ directory. The reason is that the code does not write immediately to a file, but to a file in /tmp, and then moves the file to the config/ directory.
This reply was modified 6 months, 3 weeks ago by demon_ru.
Thank you very much for your correction. You’re absolutely right. Sorry for the wrong information.
I will check whether we can adjust it in a future release so that the directory permission is no longer required.
If you want to reduce the permissions, you can do one thing:
Create a directory on the server and grant read/write access to the web server user (so that mosparo can write to the directory). The directory cannot be inside the mosparo directory; the update process would remove it.
Copy the mosparo configuration file from the config directory into this new directory.
Copy or rename the “.env.local.dist” file to “.env.local” inside the mosparo directory.
Remove the hash sign in front of the environment variable “MOSPARO_CONFIG_FILE_PATH” (line 7) and set the path to the config file in your created directory.
After that you should be able to remove the write permission from the config directory inside mosparo (since mosparo will move the file from /tmp to your custom config directory).
Kind regards, zepich / mosparo Team
Viewing 13 replies - 1 through 13 (of 13 total)
The topic ‘Invisible spam protection (simple)’ is closed to new replies.
