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.
- according to https://community.openproject.org/wp/73855 the escaping
must only happen in the representer
- the escaping in the constructor of the storage file ancestors was
missed, so it was removed now
Some wordings around health checks was highly repetitive across
a few places. To reduce the amount of duplicated translations, they
have been moved to a common location.
The downside is, that now sidepanel components and full width components
will have to work from the same translations. This is not an issue so far,
because the translations were the same anyways.
Instead of using a plus icon, which is associated
with adding something new, we are using the reload icon
which is associated with repeating something you did before.
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.
Update the OAuth section for the XWiki provider. Since XWiki provides only public clients, there are no client secrets passed in between OP and XWiki. Thus, the UI is, for now, just a mock with a client ID.
This error is intended for cases when a method is
intentionally not implemented, because the module/class defining
it expects a subclass (or class including the module) to implement
the method.
This is intended to distinguish it from other cases, such as:
* feature not implemented yet
* edge case of a method call not yet supported
Notably it avoids the misuse of the Ruby-defined NotImplementedError,
which is only intended for much more specific scenarios:
> Raised when a feature is not implemented on the current platform. For example, methods depending on the fsync or fork system calls may raise this exception [...]
Also see https://docs.ruby-lang.org/en/master/NotImplementedError.html
Effectively we only want to allow disabling the internal wiki
for now, but we'll have to answer certain usability questions
on what happens when a provider is deleted/disabled anyways, so
we'll make it technically possible to disable any provider, even
if we might not offer it for all of them out of the box.
The most likely starting scenario to have no wikis tab is that
the internal wikis are disabled and no external wiki is configured.
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.
Jan Sandbrink