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

Different accounts may use same keychain entry #5830

Closed
ckamm opened this issue Jun 12, 2017 · 17 comments
Closed

Different accounts may use same keychain entry #5830

ckamm opened this issue Jun 12, 2017 · 17 comments
Assignees
Labels
Discussion ReadyToTest QA, please validate the fix/enhancement sev2-high type:bug
Milestone

Comments

@ckamm
Copy link
Contributor

ckamm commented Jun 12, 2017

Currently the client saves and looks up keychain entries by user + server url. This leads to problems when there are several accounts with the same identifier.

Specifics:

  • Deleting one of the accounts will wipe the keychain entries, making the second one unusable.
  • If the two accounts use different auth mechanisms (oauth2 vs http), the keychain entries get overwritten with different data.

An account should generate an additional unique identifier to disambiguate the different accounts. Care needs to be taken to make it backwards compatible.

@ckamm ckamm added this to the 2.4.0 milestone Jun 12, 2017
@ogoffart
Copy link
Contributor

If the two accounts use different auth mechanisms (oauth2 vs http), the keychain entries get overwritten with different data.

That's not possible, the client uses oauth2 always if the server supports it. Even if the account was configured with basic http auth before, it will then switch to oauth2 on the next connection.

@SamuAlfageme
Copy link
Contributor

Related behavior for the cookies on log out/account removal: #5383 (comment)

@ckamm
Copy link
Contributor Author

ckamm commented Jun 12, 2017

@ogoffart Then there's some other bug lurking there, because I set up a new oauth2 account. Restarted the client and one of the two accounts pointing to the same server was signed out for no apparent reason. I guessed that the http-account's persist() overwrote some oauth keychain data...

@guruz
Copy link
Contributor

guruz commented Jun 12, 2017

An account should generate an additional unique identifier to disambiguate the different accounts. Care needs to be taken to make it backwards compatible.

Remember that this might be a quite exotic setup, so don't introduce too much complexity for this.
Maybe WONTFIX? Or whatever @ogoffart says?

@SamuAlfageme
Copy link
Contributor

An account should generate an additional unique identifier to disambiguate the different accounts.

Couldn't we simply use the id from the .cfg file also to reference the accounts on the keychain, etc... (i.e. the N in N\config_key=config_value)

[Accounts]
0\Folders\1\ignoreHiddenFiles=true
0\Folders\1\journalPath=._sync_fd41dc4a0d48.db
0\Folders\1\localPath=/Users/ownCloud/
0\Folders\1\paused=false
0\Folders\1\targetPath=/
0\authType=http
0\http_oauth=false
0\http_user=admin
0\serverVersion=10.0.2.1
0\url=https://demo.owncloud.com
0\user=admin
1\Folders\2\ignoreHiddenFiles=true
1\Folders\2\journalPath=._sync_8da9d25ef3ff.db
1\Folders\2\localPath=/Users/ownCloud2/
1\Folders\2\paused=false
1\Folders\2\targetPath=/
1\authType=http
1\http_oauth=false
1\http_user=demo
1\serverVersion=10.0.2.1
1\url=https://demo.owncloud.com
1\user=demo
version=2

Remember that this might be a quite exotic setup

Can be exotic yup, but if allowed (#5305) I think it should be done with unique account id's since otherwise it may have collateral effects for the people that use the client in that way (having the same account multiple times) 🤔

@ckamm
Copy link
Contributor Author

ckamm commented Jun 13, 2017

@guruz I think that if it's a supported feature we should care about the related bugs (but not with high priority since few people see it). If we don't want to support these setups altogether we should remove the ability to create multiple accounts for the same server in the first place.

@phil-davis
Copy link
Contributor

the ability to create multiple accounts for the same server in the first place

Just checking that here you mean some sort of "weird" setup where someone adds the same account on the same server multiple times.

Having multiple different accounts set up on the client that are all on the same server works fine, and is a reasonable thing to do (well, I do it)

@ckamm
Copy link
Contributor Author

ckamm commented Jun 14, 2017

@phil-davis Yes, thanks for the clarification. I meant several accounts pointing to the same user on the same server.

@ogoffart
Copy link
Contributor

This might actually be a problem for oauth where the refresh_token can only be used once.

@guruz guruz added sev2-high and removed sev4-low labels Jul 21, 2017
@guruz
Copy link
Contributor

guruz commented Jul 21, 2017

Upgraded to p2.
Gold ticket?

@ogoffart
Copy link
Contributor

What should happen (not tested, because the oauth2 app currently does not allow several connections) is that one of the account connects and the other re open the browser. Not too bad.
If we change the way we store in the keychain then we need an upgrade path.
And does having twice the same account make any sense?

@guruz
Copy link
Contributor

guruz commented Jul 25, 2017

because the oauth2 app currently does not allow several connections

but it will..

If we change the way we store in the keychain then we need an upgrade path.

ack

And does having twice the same account make any sense?

Yes, we had agreed that this shall be possible because users are doing things we don't imagine (e.g. they sync the same account to both their HD and a USB drive)
I'm also doing this for testing scenarios.

@ogoffart
Copy link
Contributor

Tested with owncloud/oauth2#65 and everything works perfectly as we can re-use the refresh_token several time.

@SamuAlfageme
Copy link
Contributor

Tested with owncloud/oauth2#65 and everything works perfectly as we can re-use the refresh_token several time.

Pointed out in owncloud/oauth2#70 since that should be solved in the future and we might need to adapt to get a deterministic behavior.

@SamuAlfageme
Copy link
Contributor

Another issue with current implementation: after #5752 removing an account could have the collateral of login out the other one when the client is restarted.

@ckamm
Copy link
Contributor Author

ckamm commented Sep 12, 2017

It's a bit painful due to migration, but I can take care of it.

@ckamm ckamm self-assigned this Sep 12, 2017
ckamm added a commit that referenced this issue Sep 12, 2017
This requires a lot of migration code: the old entries need to be read,
saved to the new locations and then deleted.
ckamm added a commit that referenced this issue Sep 13, 2017
This requires a lot of migration code: the old entries need to be read,
saved to the new locations and then deleted.
ckamm added a commit that referenced this issue Sep 15, 2017
This requires a lot of migration code: the old entries need to be read,
saved to the new locations and then deleted.
@ckamm ckamm added the ReadyToTest QA, please validate the fix/enhancement label Sep 15, 2017
@SamuAlfageme
Copy link
Contributor

SamuAlfageme commented Oct 24, 2017

Tested with different upgrade and multiaccount scenarios and all of them ran perfectly smooth. 🎉

Closin' here 👍 Very nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion ReadyToTest QA, please validate the fix/enhancement sev2-high type:bug
Projects
None yet
Development

No branches or pull requests

5 participants