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

Deleting passcode doesn't disconnect the client #36146

Open
HanaGemela opened this issue Sep 3, 2019 · 7 comments
Open

Deleting passcode doesn't disconnect the client #36146

HanaGemela opened this issue Sep 3, 2019 · 7 comments

Comments

@HanaGemela
Copy link
Contributor

Server: 10.3.0 alpha2 (testing)
Client: 2.6.0-daily20190820 (build 12341)
macOS 10.14.6

  1. On the server go to Settings -> Security
  2. Enter 'App name' at the bottom of the page
  3. Hit 'Create new app passcode'
  4. Log in with the passcode in the desktop sync client
  5. Delete the passcode

Actual result: Client is still connected even though the delete button on the server has 'Disconnect' tooltip.
Expected result: Client has been disconnected

@michaelstingl
Copy link

Expected result: Client has been disconnected

I think it disconnects with some delay. (Session is still valid, you could verify with mitmproxy)

@HanaGemela
Copy link
Contributor Author

HanaGemela commented Sep 3, 2019

After one hour it is still connected. When I change a password, the client asks for a new one after around 4 minutes

@michaelstingl
Copy link

@HanaGemela Quit the client, then restart?

@jvillafanez You were working with the sessions recently, could you have a look?

@guruz
Copy link
Contributor

guruz commented Sep 3, 2019 via email

@HanaGemela HanaGemela transferred this issue from owncloud/client Sep 3, 2019
@HanaGemela
Copy link
Contributor Author

With 10.2. :

Screenshot 2019-09-03 at 15 37 33

@HanaGemela
Copy link
Contributor Author

Selective sync list knows it is not connected with 10.2 server almost immediately. Even though the client shows it is connected. With aplha2 everything looks connected

@davitol davitol added this to the QA milestone Sep 3, 2019
@jvillafanez
Copy link
Member

I've checked some places where I expect the code should go through but it didn't. I think the passcode is used only for the "initial" authentication, then the next requests use the session created without using the passcode. The session itself is still valid even though the passcode isn't.

The problems we have are:

  • we can't change session information from a different session even if both sessions belongs to the same user (I can't say 100% sure, but it seems a security constraint)
  • if the clients don't send the passcode on each request (which probably they shouldn't) the server can't know whether the passcode is valid or not. The server doesn't have anything to compare.

A possible solution could be to store the passcode inside the user session. Having the association session -> passcode , we could logout from the session if the associated passcode is invalid or missing.

I don't think the solution will be ready within 10.3 taking into account we'll be touching session code. We'll need to manually tests all the authentication mechanisms again.

If someone can explain why it works with 10.2.....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants