Description of problem: Luci page header provides rel links to 'search_form', 'author' and 'sitemap' which do not exist and result in portal error message and non-fatal tracebacks when opened. Version-Release number of selected component (if applicable): luci-0.12.2-64.el5 How reproducible: Always Steps to Reproduce: 1. Check the rel links provides in luci page header 2. Try to open any of the last three Actual results: No content and traceback. Expected results: The pages should not traceback or not exist at all. Additional info: The rel links provided in the page source: <link rel="search" href="https://mycluster.example.com:8084/luci/search_form" title="Search this site" /> <link rel="author" href="https://mycluster.example.com:8084/luci/author/" title="Author information" /> <link rel="contents" href="https://mycluster.example.com:8084/luci/sitemap" title="Site Map" />
Created attachment 608100 [details] logs
Thanks, Radek. In fact, there is more places like this, but generally this technical debt regarding templates is very minor. I prefer solving this bug (as batch of templates editting) together with any other requiring to modify Data.fs. For the time being, this bug can be used to track all these tiny things that will show up. In parallel, some of them are tracked in luci/TODO [1], such as completely disabling the "forgotten password" feature, which equally well cannot be triggered in a standard-user mode (as opposed to nit-picking-tech-savvy one). [1] http://git.fedorahosted.org/cgit/conga-luci-1stgen.git/tree/?h=RHEL5-active
Attaching [bug 514679], credit for discovery belongs to Radek (who unfortunately didn't look into conga's bug history to find it reported ages ago).
Another thing: there is (AFAIK) JS-based title rewriting that works everywhere except for "cluster" tab, making it inconsistent.
The next one is that every explicit logout is accompanied with > 2012-11-09T20:26:47 INFO CMFFormController > You have triggered the form controller action "logout" using > a GET REQUEST. This is a potential security hazard. > In Plone 3.0 this will FAIL unless you explicitly enable your form > to support GET requests in the ZMI (or using the .metadata file). in /var/lib/luci/log/event.log. This could be prevent by turning "log out" link into trigger of a POST form with hidden ":default_method=logout" parameter.
re: [comment 4]: This will be kept, only non-rewritten titles will change from: <page title> — <portal title> to <Capitalized portal title> — <page title> so that it conforms to the format in rewritten titles (i.e., no harassing inconsistence).
re [comment 5]: This seems to be outside our scope, it's rather an internal Plone inconsistency (or, less likely, leftover from historic updates). The action handler is declated in: > CMFPlone/profiles/default/actions.xml
Recap: > - non-existent pages linked from page head section ('search_form', 'author' > and 'sitemap') Radek knows best :) The only <link> tag kept is the one referring to the main page (should point to /luci), as it indeed exists. > - disabled sending recovery email in (failsafe_)login_form completely IIRC, was possible when logged in and accessing /luci/require_login, /luci/login_form or something like that. Will look at more if cannot be located. Originally, it lead to non-servable address. > - JS-based title rewriting in cluster tab It would be swimming against the stream, so I instead made JS-based and native titles more consistent: see [comment 4]. Visible change at /luci/homebase, luci/storage (native titles) -- now they should conform to /luci/cluster, /luci/homebase?pagetype=2 and others where JS rewriting applies (basically all three-items-titles like "Luci - foo - bar"). > - logout action using more appropriate request method More like internal Plone implementation/integration issue, see [comment 8] and [comment 9]. Not addressed, nor a big deal with that.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1358.html