Feedback from devs that were confronted with the "is not an allowed host"
message shows, that the message is not very actionable. It's not clear why something
that is clearly a legitimate and existing host would be considered "not allowed".
The new error message clearly points at the SSRF policy as the source. Making the
problem more search engine friendly and hopefully allowing admins to better understand
what they have to fix.
Refactors the custom `:list`/`:list_item` selectors onto CAS's
`add_role_selector` and drops the now-native `Capybara::Node::Simple#role`
hack. `:list_item` resolves the listitem role, so specs matching
non-listitem `<li>` are updated (`have_row` for the custom field table,
presentation dividers via CSS).
CAS 0.16 also resolves role selectors by computed role and accessible
name, which our CSS-styled tables and Primer menus do not expose through
plain markup. Affected feature specs switch to robust locators:
Capybara's `:table_row`, the FullCalendar `data-date`, and the action
menu's real accessible name ("Edit status").
The `:columnheader` `colindex` filter lost its off-by-one offset and now
uses the true 1-based `th` position. Also fixes Webhooks `RowComponent`
spec capitalization.
It's like OpenProject::Cache, but it encrypts cached
values at rest. Callers that store confidential things in the cache
have been updated to use it, reducing the risk to expose secrets
to an attacker that obtained access to the contents of OpenProject's cache.
Don't allow to point two project storages to the same project_folder_id
if one of them is automatically managed. This ensures that ownership is
always consistently applied according to one project only.
The idea is to reuse them in the wikis module and probably elsewhere
as well, offering a similar look & feel.
The ReportComponent has been lightened for this, though. Previously
it included the page layout and a default to render when there was
no report. Now it only focusses on rendering an actual report and
leaves the rest up to the including component or page.
This is part of making health reports available to other modules
than storages as well. The base classes are essentially free of relevant
references to the storages module and only contain the glue code necessary
to fill a health report properly.
So far they have only been stored in the Rails cache, making
them pretty volatile. They are now properly stored in the database,
theoretically allowing to also retrieve older health check results and
compare them to newer ones.
Translation responsibilities have been moved into respective components,
that are rendering the results.
This is part of a refactoring that moves health reports and their components
out of the storages module into the core, allowing them to be reused by different
modules.
We already did this for the check of the team folders app,
but apparently forgot to do it for other dependencies too.
The main motivation is that an error would prevent all other
health checks from running, even if we are just behind by one
patch level.
It should be enough to show a warning to users when the version
does not match expectations, but it's not a hard error that should
prevent further health checks.
After seeing error reports about folders that would not synchronize
properly, I realized that we had no way for an admin to quantify whether
all project folders exist or for how many the creation failed.
The two new checks should cover two important questions:
* Have all project storages already synced and created a project folder?
* Is there any project storage that has a linked project folder, but it's missing?
It's unclear to us why the creation of folder A should
also prevent the creation of folders B, C, D, E and F.
Most of the code around this is written in a way that it would
be fine with partial failures.
If no tests fail as a consequence of this change, I am inclined to
merge it.
This affects the section for "automatically managed project folders",
which actually does not indicate the time at which a dedicated health
CHECK was performed, but rather indicates the last time that an
AMPF sync was attempted and whether that succeeded or not.
This is confusing to users, because seemingly we have two health checks,
when in fact there's just a single health check. The AMPF job is a job
that performs a task and it can do so successfully or not. Hopefully this
change makes it more clear to users that if an error occurs during AMPF
sync, that something went wrong.
* Removed unused objects... it seems some tests still relied on them.
* Adds validation keys that where missing
* Update the AMPF validator chaging the create folder validation
* Error handling on FileInfo validation and tests for the Site/List case
* Fix sharepoint factory to include the trailing slash
Co-authored-by: Jan Sandbrink <j.sandbrink@openproject.com>
Jan Sandbrink