Calling any apps API fails if using header authorization

[chris-bird-coolearth]

I will use Passman & Gallery for this example, although this affects every app I've tested (all tests must be done logged out of owncloud, ideally in private window)

Steps to reproduce

1. curl -u user:pass or using the header "Authorization Basic xxxxxxxx" https://example.com/index.php/apps/passman/api/v2/vaults
2. First load response will be empty or error
3. Refresh will load as expected (not curl)

Expected behaviour

API should respond with the correct data if the authorization is there and correct

Actual behaviour

The first request returns an empty response, or an error depending on the app, Passman returns empty as is discussed here nextcloud/passman-webextension#253 Gallery returns "Message: Call to a member function getPath() on null" cookies test & session get set in the headers, on refresh it returns the data that should be returns, if using no headers, or the wrong login it forwards to the owncloud login page as expect. I've tested this on the Owncloud demo site and am getting the same problem, on refresh it works

Steps to reproduce on demo.owncloud.com:

1. Set headers in Firefox with Modify Header Value to "Authorization: Basic ZGVtbzpkZW1v"
2. Open https://demo.owncloud.com/index.php/apps/gallery/api/config in an private window and you will get "Internal Server Error"
3. Refresh the page and it will return the correct JSON data

Server configuration

Debian 8

Web server:Apache

Database:MariaDB

PHP version:7.1

ownCloud version:10.0.8 (see ownCloud admin page)

Updated from an older ownCloud or fresh install:fresh

Where did you install ownCloud from:apt

Are you using encryption: yes

As this issue is reproducable on the owncloud demo server, I won't anything else for now unless needed, I will add though that there are no errors produced in the log (I've got logging set to debugging) there are also no errors displayed in the browser for this issue, a 500 does come from the gallery API but that's due to the fatal error caused by this issue.

[ownclouders]

GitMate.io thinks the contributor most likely able to help you is @PVince81.

Possibly related issues are #28070 (enable apps failed), #3153 (API is broken), #3061 (API - failed response BUG), #7086 (Add public API to load other apps), and #19958 (Streaming API?).

[patrickjahns]

@DeepDiver1975 - I have observed the same behavior when automating regression testing for creating app passwords ("tokens"). I first needed to create a signed in request and receive cookies, to be able to directly access token endpoints.

Once we know if this is expected/intended behavior - I propose to define desired behavior in api tests and roll them out - cc @phil-davis @individual-it @davitol

[DeepDiver1975]

The trouble is within the apps - e.g. https://github.com/owncloud/gallery/blob/90e260fcb3e2b226b3c2a39bd194cf195bf0b361/environment/environment.php#L113

Since 10.0.7(?) the user id might in some cases only be available within the controller methods after the security middleware did it's job.

This is the breaking change in core: #30421

[DeepDiver1975]

Maybe we remove 'UserId' from the DIContainer .... or at least spit out a warning...

core/lib/private/AppFramework/DependencyInjection/DIContainer.php

Line 305 in 35eb867

return $c->query('OCP\\IUserSession')->getSession()->get('user_id');

[PVince81]

Likely related #22666

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[stefan-schilling]

unstale

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed.