- our APIv3 relies on having a non-null user
- if all auth strategies fail, the anonymous user is set to User.current
- bcf api is mounted in the root api - path is /api/bcf/v2_1 - that is
the reason for the need of being able to fallback to anonymous user in
the bcf api scope
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
This class got broken during what seems to be a
drive-by style-improvement in fbe1215365. That change:
* made it incompatible with frozen strings as error messages
* broke the intended hiding of messages if they came from the
wrong class
All of this went by unnoticed, because there were no specs
for the InternalError class.
Specs have now been added and the previous version of the code
mostly restored. Since there were some callers that always created the
exception with known safe error messages, I added a new class just for these
cases, because they were intended to "just show the message". So we can
keep using the original implementation for rescue_from handling.
https://community.openproject.org/wp/65138
The seeders now have the ability to declare the attributes containing
references to other objects. If those references are missing, the seeder
will not run.
This is used on some seeders to avoid raising an error when seeding on
an instance without any workflows (see bug 65138)
This will be required to use warden for our SCIM endpoints as well,
which are implemented in rails controllers. Since Rails controllers do
not support mounting rack middlewares partially (the way that e.g. Grape does),
the mounting of warden needed to be moved.
This was not super straight-forward, because of load order issues:
* Requiring a Rails middleware must be done before initialization finished
* Our warden config was so far done _after_ initialization
* static_routes were defined in lib, which is automatically reloaded,
but auto-reloading code is not allowed during initialization
* lib_static which is autoloaded_once is fine during init,
this is also where the rest of warden authentication is defined
Additionally warden was configured to not handle HTTP 401 responses generated
by the upstream app itself. Warden will only be responsible for its own authentication
failures and it's still possible to invoke the warden failure app by throwing the :warden
symbol, but the application keeps its capability of responding with custom 401 responses.
Oliver Günther