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

Unify the core sync logic #29669

Merged
merged 1 commit into from
Feb 3, 2018
Merged

Unify the core sync logic #29669

merged 1 commit into from
Feb 3, 2018

Conversation

tomneedham
Copy link
Contributor

@tomneedham tomneedham commented Nov 23, 2017

remove some code duplication and get the core to run a proper sync on the user metadata during a login

@DeepDiver1975 @PVince81 note that the account table introduced a change in behavior:
setDisplayName() was no longer called on the backend while canChangeDisplayName() would still check the backend if it implemented that function. With the account table we can always change display name, email, avatar ... but we may want to prevent that. canChangeDisplayName() already contains a check on the system value allow_user_to_change_display_name. canChangeAvatar() and canChangePassword() already exist, but email is missing.

Conceptually there are now two cases for setDisplayName:

  1. End user triggered in the UI. Changeability may depend on the backend, eg LDAP is readonly.
  2. Sync triggered.

The current User object code is intended only for the first case.

@tomneedham we need to add a codepath for the second case. AFAICT we should directly work on the accounts... the sync case bypasses any end user limitations.

@DeepDiver1975
Copy link
Member

Tests hate you 😢

@@ -216,10 +221,13 @@ public function checkPassword($loginName, $password) {
if ($uid !== false) {
try {
$account = $this->accountMapper->getByUid($uid);
$this->syncService->setupAccount($account, $backend, $account->getUserId());
Copy link
Member

@butonic butonic Nov 27, 2017

Choose a reason for hiding this comment

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

  • move to a different place that is also executed after login via apache / saml

@tomneedham
Copy link
Contributor Author

CacheTest seems to not find the displayname on a test user.. weird

@codecov
Copy link

codecov bot commented Nov 29, 2017

Codecov Report

Merging #29669 into master will increase coverage by 45.02%.
The diff coverage is 58.69%.

Impacted file tree graph

@@              Coverage Diff              @@
##             master   #29669       +/-   ##
=============================================
+ Coverage     15.82%   60.84%   +45.02%     
- Complexity      920    18549    +17629     
=============================================
  Files            51     1092     +1041     
  Lines          3356    61280    +57924     
=============================================
+ Hits            531    37287    +36756     
- Misses         2825    23993    +21168
Impacted Files Coverage Δ Complexity Δ
lib/private/User/Account.php 73.91% <ø> (ø) 9 <0> (?)
core/Migrations/Version20170221114437.php 0% <0%> (ø) 2 <1> (?)
core/Command/User/SyncBackend.php 0% <0%> (ø) 24 <7> (?)
lib/private/legacy/user.php 22.98% <0%> (ø) 72 <0> (?)
lib/private/User/Database.php 72.03% <100%> (ø) 43 <0> (?)
lib/private/User/User.php 83.52% <100%> (ø) 64 <0> (?)
lib/private/Server.php 82.84% <100%> (ø) 129 <0> (?)
lib/private/User/Session.php 58.91% <34.88%> (ø) 139 <14> (?)
lib/private/User/SyncService.php 57.86% <63.3%> (ø) 55 <52> (?)
lib/private/User/Manager.php 82.01% <83.33%> (ø) 50 <2> (?)
... and 1042 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f8f428d...05a82b5. Read the comment docs.

@tomneedham
Copy link
Contributor Author

tomneedham commented Nov 29, 2017

I most definitely just broke stuff - but I hope the logic is right.... LDAP login works, DB users work, saml seems to die.

Made PRs in LDAP owncloud/user_ldap#156 and Shibboleth https://github.com/owncloud/user_shibboleth/pull/208 to move sync to core

@tomneedham
Copy link
Contributor Author

screen shot 2017-11-29 at 20 54 36
Safe to say stuff broke...

@tomneedham
Copy link
Contributor Author

tomneedham commented Nov 29, 2017

Ok - fixed saml. But, for some reason the home path is not set so when you login with a new user they done have a home and you get some weird error about symlinks

Edit: checked with master of core and user_shibboleth: by default, we somehow get a default home path

@tomneedham
Copy link
Contributor Author

Fixed to use default home path if backend does not provide one.

However - this could break the home path during a sync if the backend suddently cannot provide a path or provides an invalid path.... I will add a check to not reset it

@tomneedham
Copy link
Contributor Author

  • core should validate emails before setting them to oc_accounts.email

@tomneedham
Copy link
Contributor Author

  • Might have killed some pre and post create user hooks

@tomneedham
Copy link
Contributor Author

Since the syncservice now does user creation, maybe the hooks wont be connected properly anymore...

@tomneedham
Copy link
Contributor Author

I did slightly re-order the hooks here, preCreateUser is now called after the validatePassword GenericEvent...


$uid = $backend->getCurrentUserId();
if ($uid === $this->getUser()->getUID()) {

if ($this->getUser() != null && $uid === $this->getUser()->getUID()) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

If session is active and current session uid matches the request user id then we are authenticated and have nothing more to do

// Die here if not valid
if(!$backend->isSessionActive()) {
return false;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is redundant. OC_User::handleApacheAuth will only call this method if there is already an active IApacheBackend with an active session

private function syncHome(Account $a, UserInterface $backend) {
// Home is handled differently, it should only be set on account creation, when there is no home already set
// Otherwise it could change on a sync and result in a new user folder being created
if($a->getHome() === null) {
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if we should do something if the home is different between the account and the backend. As annoying as it will likely be, a warning message saying that we're refusing to update the home folder might be a good idea, specially if the admin expects the home to be updated. Since we don't have any command to change the home folder of a user, I think this is enough; the admin should revert the change in the backend.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense to at least output something here - because the admin should be aware.

// completed before we can safely create the users folder.
// For example encryption needs to initialize the users keys first
// before we can create the user folder with the skeleton files
//OC_Hook::emit("OC_User", "post_login", ["uid" => $uid, 'password' => '']);
Copy link
Member

Choose a reason for hiding this comment

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

@tomneedham wrong hook? remove line?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

@tomneedham
Copy link
Contributor Author

Started writing tests. Couldn't mock $backend->getHome because it doesnt exist in UserInterface. Talked to @DeepDiver1975 - so just went the whole way and added interfaces for providing a home and providing a displayname.

@butonic butonic merged commit cfd797e into master Feb 3, 2018
@butonic butonic deleted the sync-after-login branch February 3, 2018 08:49
}

// Now we try to create the account or sync
$this->userSyncService->createOrSyncAccount($uid, $backend);
Copy link
Contributor

Choose a reason for hiding this comment

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

This means each new login with result in sync, right?

* @param UserInterface $backend of the user
* @return Account
*/
public function syncAccount(Account $a, UserInterface $backend) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Isnt it 10 calls to LDAP just for one login? @DeepDiver1975 @butonic @tomneedham

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess no way it can be 1 call right?

@mrow4a
Copy link
Contributor

mrow4a commented Feb 4, 2018

Well have to admit, this PR cleaned up a lot of things... code looks now... like a code and not spaghetti ;d

$this->mapper->update($a);
} catch(DoesNotExistException $ex) {
$a = $this->createNewAccount($uid);
Copy link
Contributor

Choose a reason for hiding this comment

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

change in this line fixed/reverted by #30367

@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