Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[stable10] Missing oc_authtoken (session) for native clients #28879

Merged
merged 2 commits into from
Nov 10, 2017

Conversation

IljaN
Copy link
Member

@IljaN IljaN commented Sep 1, 2017

Description

oc_authtoken was not created for clients which use basic auth. (Probably everything, except browser and some dav-clients)

Related Issue

fixes #27845
fixes #28553
fixes #28881

Motivation and Context

This bug was introduced with commit f1dc2d9 - "Validate session only if we are not in a basic auth request".

Looking at the commit message the intent is not quite clear to me because the dektop client and all the mobile clients use basic auth at the moment. As the issue is relatively old I assume that some technical circumstances changed or that the validateSesion method is badly named because basic auth is technically not a persistent session trough requests. With this assumption the intent of the commit makes sense.

How Has This Been Tested?

Manually

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@IljaN
Copy link
Member Author

IljaN commented Sep 1, 2017

@phisch / @DeepDiver1975: Is it possible to move that session check to somwhere else? Was suprised when I saw session handling code in a method called "loadApps" ;-)))

@SamuAlfageme
Copy link

@IljaN cool, now I'm getting all the sessions logged back in the webUI 🎉

Revoking though, (using the 'Delete' button next to them) is still not working (i.e. clients using basic auth are still able to sync and keep their session - it spawns in the table on next client request). So #27845 might be deeper. Also I've noticed after removing a browser session (from a different one) and hitting:

curl 'https://<server>/index.php/settings/personal/authtokens' \
    -H 'OCS-APIREQUEST: true' \
    -H 'Cookie: $SESSION'

Server replies with 503. The rest of the endpoints is fine. No exception is raised in the logs.

@SamuAlfageme
Copy link

Described that one issue in #28881 as this one was only for the regression display.

@PVince81
Copy link
Contributor

PVince81 commented Sep 1, 2017

From my understanding from last time I looked at similar code, it seemed that there was a difference between basic auth and DAV authentication (still not sure where this is happening).

If we consider that both are two different things, then the old commit from @DeepDiver1975 was correct as it was only validating the session if we're NOT dealing with DAV authentication, so $davUser is null, in which case we're dealing with basic auth, not DAV auth.

The original issue though was that sessions did not appear in the list. Is there some piece of code inside of validateSession which we could extract and use here to make sure the session entry will be updated without validating ?

Now the other question would be whether it's really that bad to validate here additionally ?

Another concern: since you reversed the condition, it is likely that now basic auth is not getting validated any more. Maybe the if part should be removed completely ?

@IljaN
Copy link
Member Author

IljaN commented Sep 1, 2017

In my tests $davUser was always set using the sync client so go figure... Web interface does not go trough this codepath at all.

I also had the idea to pull the token update out but the code is buried in a private tokenProvider object inside session...

Yeah it would probably be the safest bet to always validate, basically reverting @DeepDiver1975 `s change.

@IljaN
Copy link
Member Author

IljaN commented Sep 1, 2017

Oh look what i found:

/**
* Add DAV authenticated. This should in an ideal world not be
* necessary but the iOS App reads cookies from anywhere instead
* only the DAV endpoint.
* This makes sure that the cookies will be valid for the whole scope
* @see https://github.com/owncloud/core/issues/22893
*/
$this->session->set(
Auth::DAV_AUTHENTICATED, $this->getUser()->getUID()
);
return true;

@PVince81
Copy link
Contributor

PVince81 commented Sep 1, 2017

It is possible that "DAV auth" means "basic auth done on a Webdav endpoint"

$user = $this->userManager->get($this->uid);
$currentToken = $this->tokenProvider->getToken($this->session->getId());

if ($currentToken->getId() == $id) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PVince81
Copy link
Contributor

PVince81 commented Sep 4, 2017

If validating in all cases isn't causing any other side effects, then I'm fine with this.

Needs to be retested at best will most authentication schemes:

  • basic auth on Webdav
  • basic auth on OCS
  • web UI session
  • shibboleth ?
  • auth with application token instead of password
  • oauth2

@IljaN
Copy link
Member Author

IljaN commented Sep 5, 2017

Will figure out how to test most of these, not sure:
...how to setup/test shibboleth and oauth2
... what exactly OCS is.

@phisch, can you help?

@PVince81
Copy link
Contributor

PVince81 commented Sep 5, 2017

@IljaN get help from QA or @SamuAlfageme for testing these cases

@SamuAlfageme
Copy link

SamuAlfageme commented Sep 5, 2017

Some results after some quick checks:

  • ✅ basic auth on Webdav
  • ✅ basic auth on OCS
  • ✅ web UI session
  • ❌ shibboleth
  • ✅ auth with application token instead of password
  • ✅ oauth2

sessions

About Shib, I'm not sure if the sessions ever appeared in this section (or they have a separate pane somewhere; kind of like it happens with OAuth)

Here ya go with a normal SAML request if that can help out determining if something is missing:

SAML-Authenticated PROPFIND
curl \
-H 'Cookie:oc_sessionPassphrase=7hZcZNUIb3AaiNocC%2BIXh5aAYM36%2F3R1WG6i6OltcbqdYsJhHTorkR8%2BgQcmTZL7ax7CuavRwJL4GpNb2uBGPjEN2LsM2aMZ58pVCHlMzu5bMMkjzuPAvyNhwr6dgajQ; ocgwv1nxeve8=iq8npgptet00ocj15qtc2vr4g6; _shibsession_64656661756c7468747470733a2f2f646f636b65722e6f632e736f6c6964676561722e65733a31303237312f6f632d73686962=_58f8ec23b20e1ac03e7d389bad9d7197' \
-H 'Content-Length:114' \
 -X PROPFIND 'https://<server>/<shib-path>/remote.php/dav/files/alterego@testshib.org/' --data-binary '<?xml version="1.0" ?>
<d:propfind xmlns:d="DAV:">
  <d:prop>
    <d:getlastmodified />
  </d:prop>
</d:propfind>
'

@IljaN maybe we can also get the _shibsession_*=_*'s logged in the session table somehow. I don't really know the specifics about it maybe @butonic or @DeepDiver1975 can help here.

@PVince81 about

basic auth on OCS

I'm getting the "last activity" time updated from ocs calls, so I'd say that one works as expected as well. (they don't and I guess shouldn't originate new entries)

@PVince81
Copy link
Contributor

PVince81 commented Sep 5, 2017

@SamuAlfageme for shib, try with shib and the latest OC version before the regression to find out whether it ever worked before.

@IljaN IljaN force-pushed the missing_non_browser_authtoken branch from 8f39c1d to ed85adc Compare September 6, 2017 08:36
@PVince81
Copy link
Contributor

PVince81 commented Sep 6, 2017

lots of failing integration tests, like "auth.access files app with basic auth"

@IljaN IljaN force-pushed the missing_non_browser_authtoken branch from 99d1df6 to 6ea527b Compare September 7, 2017 16:34
@IljaN
Copy link
Member Author

IljaN commented Sep 7, 2017

All tests should pass now 🤞
Altough the code feels like a hack...

@IljaN
Copy link
Member Author

IljaN commented Sep 8, 2017

@SamuAlfageme All tests are green now, please retest.

@IljaN
Copy link
Member Author

IljaN commented Nov 8, 2017

@davitol I can confirm that cadavre session is not displayed... investigating

@IljaN IljaN force-pushed the missing_non_browser_authtoken branch from 1967464 to ac7057d Compare November 8, 2017 15:48
@IljaN
Copy link
Member Author

IljaN commented Nov 8, 2017

@davitol We figured out that cadaver does not support cookies thus doing basic auth on every request. This is why nothing is displayed in the sessions view because there is technically no session established. This would explain why Cyberduck is displayed (it probably supports cookies)

After discussing with @DeepDiver1975 the expected behavior is that nothing is displayed for clients which do not support cookies.

If we would "fix" that, we would have a entry for every request made by cadaver.

As for the iOS issue I need to find someone with a iPhone to be able to debug this...

PS: I will try to replicate the issue with Android

@davitol
Copy link
Contributor

davitol commented Nov 8, 2017

PS: I will try to replicate the issue with Android

@IljaN With Android it went fine for me

screen shot 2017-11-08 at 17 39 08

@jesmrec
Copy link

jesmrec commented Nov 9, 2017

@IljaN the point is the way the iOS client is handling with the cookies. Some request are including authorization basic header but no cookies, therefore the server answers with a new cookie, and i guess that in this case a new row is included there. We will take care

@PVince81
Copy link
Contributor

PVince81 commented Nov 9, 2017

@jesmrec so can we merge this or will this require modifications of the PR code ?

@jesmrec
Copy link

jesmrec commented Nov 9, 2017

@PVince81 you can merge

@PVince81
Copy link
Contributor

@jesmrec thanks.

Now for a last CI battle then we can merge.

Current token must be not null

Generate auth token for http_basic_auth logins

Cleanup
@PVince81 PVince81 force-pushed the missing_non_browser_authtoken branch from ac7057d to de3597a Compare November 10, 2017 11:14
@PVince81
Copy link
Contributor

Rebased for CI, hopefully for higher timeout values

@PVince81
Copy link
Contributor

codecov errors about the legacy app code, passing on this one 🙈

@PVince81 PVince81 merged commit dc57c65 into stable10 Nov 10, 2017
@PVince81 PVince81 deleted the missing_non_browser_authtoken branch November 10, 2017 13:48
@PVince81
Copy link
Contributor

@IljaN please forward port to master

@lock
Copy link

lock bot commented Aug 1, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants