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
The intention of this change is to always respond in the metadata-rich
version of the header that indicates things like the required scope and
the URL of the resource_metadata endpoint, which was previously hidden
and only visible if clients used a non-standard HTTP request header.
semantically it's probably the preferable version of the header by now
anyways, because:
* all APIs accept some kind of Bearer token, not all of them accept Basic auth
* Even API tokens can now be passed as Bearer tokens
Practically the Basic auth header also caused unintended browser pop-ups when the frontend
code didn't include the correct request header to avoid the Basic auth offer, this now can't
happen anymore, since the Basic auth version of the header is only returned, if the client actively
tried to authenticate through Basic auth.
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.
Accessing the API currently does not, and should not update the user's session.
Still, currently we're using it to access the session for authenticating the user.
As a result, the session is loaded and we're currently outputting a Set-Cookie header as well as
writing the user session on every API request.
By using session_options[:skip], we can tell rack to avoid saving the session after the request
Updates the copyright to 2021 for all files that have a copyright. Files in our source code without the copyright header still do not receive one automatically. Additionally, backlisted files are also excluded.
Previously the copyright of chiliproject which references redmine stated a copyright of redmine up to and including 2017 which is not true for the code we have in here. Because of that I changed that to 2013
Instead of warden responding with 401 "unauthorized", use our own
error response that correctly sets the `WWWW-Authenticat` header.
We tripped into the default 401 error that does not output any headers
if we're not returning any users.
This was caused by another issue: The `session` object may be
present, even though no session id exists. Checking `session&.id`
instead always yields the anonymous user.
This will ensure consumers of APIV3 to always get a JSON / HAL response
as well.
https://community.openproject.com/wp/32486
Jan Sandbrink