Just installed latest plone 5.2 on ubuntu 20.04 as zeocluster. I've installed plone before (since v.2) as standalone, but I'm stumped here, as the site seems to work ok when accessing through ssh-tunnel and localhost:8080. After I create a new user as admin, terminate tunnel and try to log into front-end, I get "There was an error loading modal." or no response at all. Tried with creating another new higher privileged user - same outcome.
It seems that there is something not registering, or perhaps there is a permissions issue (just a hunch)
tail from event.log
2020-07-06 21:46:14,263 WARNING [Init:86][MainThread] Class Products.CMFFormController.ControllerPythonScript.ControllerPythonScript has a security declaration for nonexistent method 'ZPythonScriptHTML_changePrefs'
2020-07-06 21:46:14,268 WARNING [Init:86][MainThread] Class Products.CMFFormController.ControllerValidator.ControllerValidator has a security declaration for nonexistent method 'ZPythonScriptHTML_changePrefs'
2020-07-06 21:46:14,741 INFO [Products.PloneHotfix20200121:49][MainThread] Applied sql_quote patch
2020-07-06 21:46:14,797 INFO [Products.PloneHotfix20200121:49][MainThread] Applied in_portal patch
2020-07-06 21:46:14,798 INFO [Products.PloneHotfix20200121:49][MainThread] Applied password_validation patch
2020-07-06 21:46:14,808 INFO [Products.PloneHotfix20200121:49][MainThread] Applied pac patch
2020-07-06 21:46:14,823 INFO [Products.PloneHotfix20200121:49][MainThread] Applied content patch
2020-07-06 21:46:14,828 INFO [Products.PloneHotfix20200121:49][MainThread] Applied layout patch
2020-07-06 21:46:14,908 INFO [Products.PloneHotfix20200121:49][MainThread] Applied restapi_local_roles patch
2020-07-06 21:46:14,909 INFO [Products.PloneHotfix20200121:57][MainThread] Hotfix installed
2020-07-06 21:46:15,055 INFO [ZEO.ClientStorage:202][MainThread] zeostorage ClientStorage (pid=83196) created RW/normal for storage: '1'
2020-07-06 21:46:15,056 INFO [ZEO.cache:208][MainThread] created temporary cache file 7
2020-07-06 21:46:15,062 INFO [ZEO.asyncio.base:51][zeostorage zeo client networking thread] Connected Protocol(('127.0.0.1', 8100), '1', False)
2020-07-06 21:46:15,069 INFO [ZEO.ClientStorage:362][zeostorage zeo client networking thread] zeostorage Connected to storage: ('localhost', 8100)
2020-07-06 21:46:15,072 WARNING [TemporaryStorage:93][MainThread] DEPRECATED: Usage of the package tempstorage is deprecated, as it is known to randomly lose data.
Especially on Zope 4. For details see https://github.com/zopefoundation/tempstorage/issues/8
and https://github.com/zopefoundation/tempstorage
2020-07-06 21:46:19,449 INFO [Zope:45][MainThread] Ready to handle requests
Was this a message generated by JavaScript/the browser? "modal" indicates this way. In this case, I would use a browser development tool (e.g. the "network analysis" from the "firefox" developer tools) to check what requests are sent by the browser to the server and whether some of those fail. If you see a failing request, you could analyze it via the error_log object responsible for the request. error_log is a Zope object accessed via the ZMI (= "Zope Management Interface"); responsible for a request is the nearest ancestor error_log of the request's "published object". error_log manages detailed information about exceptions from the publishing. By default, it ignores some (frequent) exception types. You may need to reconfigure the respective error_log to get information regarding your specific case.
Access to XMLHttpRequest at 'http://halflight.org/login' from origin 'http://www.halflight.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Unsure how to change the nginx config to prevent this, but at least I know where to explore.
Great resource, thanks!
tl;dr: how come a policy is enforced while the nginx config file for this site is only enforcing Content-Security-Policy-Report-Only. Is it the earlier these lines
Longer Answer: I will dig into it – no choice really – but I'm still confused why a policy is being enforced while my header add-ons as per the plone 5.2 docs. Content Security Policy (CSP) is mentioned right after the example of the nginx configuration file that also has the suggested security headers that should supposedly fix this problem. I note that the CSP is only set to Content-Security-Policy-Report-Only, not actually enforcing it as that line is commented out on purpose.
/rant
I did not mention this earlier, bu it isn't only js that gets rejected upon login. The first thing that the js console shows is even a rejection of certain style sheets upon first load! And this is while having installed the latest STABLE 5.2 on a freshly initiated Ubuntu 20.04LTS VPS on Linode. No cruft there. Following the docs. I've been with plone on and off for years now, and it is still so very hard to love it when getting it to run is fraught with gotchas and glitches like this
/rant
Problem has been resolved (for the most part, fonts still missing). Details to follow. Thanks for everyone's responses. It helps more than you will ever know.
RESOLVED
I was able to find and resolve the following errors in my setup:
an incomplete CSP policy in the header section of the site config file. This might be good to actually add to the default Universal Installer to prevent this from happening ever again.
a (faulty) combination of www and no-www settings in the server block and the VirtualHostMonster setup
a partially working www-no-www-TLS redirect in the nginx server block setup. There are many conflicting setups suggested online, outdated or shoehorning Apache solutions into nginx.
Solution 1: font/woff2 not loading due to CSP can be resolved by adding the "data:" snippet to the Content Security Policy where font-src is defined, like so
font-src 'self' data:;
PS: A more recent discovery is that font-src 'self' 'unsafe-inline'; is supposed to work, and if it does, is a better solution. This is only mentioned in some plone manual pages, not those I used initially. This does not work for me: without the the data snippet, all icons disappear from TinyMCE in my minty fresh installation on a brand new Ubuntu 20.04 with all dependencies properly installed and verified...
Solution 2: VirtualHostMonster seemed to work, yet the server block defined server as www and VHM as non-www with some unpredictable results. Harmonizing these resolved it.
Solution 3: Although the order of nginx redirects shouldn't matter, in (my) practice it does. Setting up the redirects in the following order works.
Just thank you for laying out your solution so clearly. I saw similar problems about a month ago. Eventually sorted them out in a similar way. Your note would have been useful and will be useful for others.