Show clients connected to the account

[jancborchardt]

Some other systems have a listing of the clients (desktop & mobile apps) which access the account. This is useful for example when you believe there’s malicious log ins or when you want to revoke a device when you lost it.

We should have something like that in the Personal settings.

cc @karlitschek @DeepDiver1975 @owncloud/designers

[zombiehugs]

I like it.

[MTRichards]

Great feature, and very important

[LukasReschke]

This should be similar to Google's "Activity on this account" tool and also includes all Web sessions. Which means, that we need a custom session handler for this since we can't iterate through active PHP sessions.

What we need to show:

• Access Type (Browser, Client, etc...) including UA
• Location (if possible) and IP address
• Date / Time when this happened

Also very handy would be an alert preference where it would alert the user if an usual behaviour has been found. (e.g. a user that always logged-in from Germany and uses Chrome has now an open-connection from a Firefox user in India)

[DeepDiver1975]

Related: we should list active sessions for the user and grant the possibility to revoke a session.

This enables to kill sessions on password change.

There is an issue for this .... somewhere.

[karlitschek]

Hint. This is the "loggedin" status. Not nesessarily the same as the technical concept "session". So it´m might in in-practical to revoce a different session but it might be possible to logout a user.

[DeepDiver1975]

Hint. This is the "loggedin" status. Not nesessarily the same as the technical concept "session". So it´m might in in-practical to revoce a different session but it might be possible to logout a user.

The idea is to store all session ids for the users in the database together with the additional information we need to display all the information as defined above.

In addition we can maintain a flag to specify if the session is valid or not (revoked by the user or revoked due to password change) and as soon as the session key 'returns' to the server we log the user out.

[LukasReschke]

I second what @DeepDiver1975 proposed. That should be straight-forward to implement.

[MTRichards]

Cool! I like this. To see all client access on an account and revoke a specific client access would be super useful.

If it is a stored password, will the app / client just log in again and get a new session?

[LukasReschke]

If it is a stored password, will the app / client just log in again and get a new session?

Yes. Because that would require OAuth support, see #10400

[MTRichards]

I understand that would be a way to do this, but now I am confused. Because without something like OAuth, removing a device from the personal tab wouldn't actually help if the client can log in again.

So this now means we would have an OAuth server inside ownCloud embedded, and the Desktop and Mobile apps use our own username / OAuth token from an ownCloud Auth server embedded in the server instead of username password like today? Wow, that is ... a significant change we need to think through. Not sure I know all of the implications of such a change, or how it would work with SAML auth, or another OAuth service, or LDAP/AD, 2 factor from vendors, etc etc.

Or did I completely miss something?

[LukasReschke]

I understand that would be a way to do this, but now I am confused. Because without something like OAuth, removing a device from the personal tab wouldn't actually help if the client can log in again.

Actually it would help against the case "logged-in in a Webbrowser Session in a coffee shop".

So this now means we would have an OAuth server inside ownCloud embedded, and the Desktop and Mobile apps use our own username / OAuth token from an ownCloud Auth server embedded in the server instead of username password like today?

This is the cleanest solution, basically we need a way to have unique tokens per client. OAuth is already a very well known standard for this and would allow us to better integrate with third-party vendors. I'd strongly advise that we implement this as well and do not invent the wheel again ;-)

Not sure I know all of the implications of such a change, or how it would work with SAML auth, or another OAuth service, or LDAP/AD, 2 factor from vendors, etc etc.

Not much things in this regard would change. Basically, the client would open "owncloud.com/requestAccess" (or something like that) in a browser where the user has to regularly authenticate himself (be it LDAP or SAML or whatever). We then have to map the generated token to this identity in our database.
Read as: This is the easiest part to implement, there are others much harder technical challenges. (see my posted issue for some examples)

Or did I completely miss something?

Nope. But that's just how it is: If the client knows the password there is not much we can do to prevent him logging in again.

[MTRichards]

Cool, thanks for the explanation. As I think through it, I am liking.

The only problem I see is that this will be necessary to be turned off in some cases. Plenty of users / admins won't want users to have to use the OAuth mechanism in ownCloud. We have to decide if we allow this or not. Is the OAuth server the only way for clients and apps to connect, or are there other options?

What if, for example, users want to mount webdav as a network drive, or use a standard webdav client that doesn't understand OAuth. We would need to have an admin switch "allow un-authorized agents" or something to allow ownCloud to handle these types of requests. If the Admin wants to control tightly authorized apps only, then great - disable basic auth. If they want it more open, we would have to be able to set these permissions by group probably.

Just thinking here out loud here, but there are a lot of cases we need to make sure we cover.

[rullzer]

@MTRichards what we could do is generate per device passwords. So if you want to mount webdav on your computer. You just use a long generated password for that. That way the user can still revoke access since there is only one app connecting using that password.

Of course OAuth is prefered but if you cannot do that because your webdav client does not support it this is an alterantive.

This is very similar to how google handles it.

[ChristophWurst]

Done in #24703

[dubsflyt]

As been as it seems to be somewhat related to this, is it possible to also on the users page have the version of the sync client that was last used with each account, would make administration far easier in terms of making sure everyone is running up to date sync clients.

[PVince81]

@dubsflyt it's too late now for 9.1 as we're past feature freeze now.
Can you open a new ticket for this enhancement ?
Thanks

[lock]

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.