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

Sessions of Desktop, iOS and Android clients should be shown #27845

Closed
davitol opened this issue May 9, 2017 · 13 comments · Fixed by #29533
Closed

Sessions of Desktop, iOS and Android clients should be shown #27845

davitol opened this issue May 9, 2017 · 13 comments · Fixed by #29533
Assignees
Labels
Milestone

Comments

@davitol
Copy link
Contributor

davitol commented May 9, 2017

Steps to reproduce

  1. Log in oC server with a oC Client (Desktop, iOS, Android)
  2. Browse to Admin --> Settings--> Personal --> Security

Expected behaviour

The User agents from the sessions of Desktop, iOS and Android clients should be shown

Actual behaviour

The User agents from Desktop, iOS and Android clients are not been shown

Server configuration

Operating system:
Ubuntu 16.04

Web server:
Apache

Database:
MySQL

PHP version:
7.0

ownCloud version:

"version":"10.0.0.1" daily master

Updated from an older ownCloud or fresh install:
Fresh

Are you using external storage, if yes which one: local/smb/sftp/...
No

Are you using encryption:
No

Logs


Client configuration

browser

Desktop Client, iOS, Android

It is shown only the ones related to browsers.

screen shot 2017-05-09 at 17 44 29

@mmattel
Copy link
Contributor

mmattel commented May 10, 2017

👍

@davitol
Copy link
Contributor Author

davitol commented May 17, 2017

@PVince81 FYI

@PVince81 PVince81 modified the milestones: 10.0.2, 10.0.3 May 26, 2017
@PVince81
Copy link
Contributor

I'm using an app specific password for mobile so the "most recent activity" is updated correctly under that session. I don't see any additional entries for this in the first section.

Interestingly I also see that the first section header says "Browser". Was it designed to only detect browsers and not mobile clients ? Not sure.

Does it work differently in 9.1 ? (might be able to bisect)

@davitol
Copy link
Contributor Author

davitol commented Jun 1, 2017

Interestingly I also see that the first section header says "Browser". Was it designed to only detect browsers and not mobile clients ? Not sure.

Does it work differently in 9.1 ? (might be able to bisect)

screen shot 2017-06-01 at 10 04 33

For example in 9.1.6 iOS session appears but not in oCX

About the header "browser" it was comment long time ago but it was not changed, I could not find the comment related to change browser as header in GH

@PVince81
Copy link
Contributor

auth / token stuff, @phisch can you have a look ? If not, let me know

@PVince81 PVince81 modified the milestones: triage, development Jun 29, 2017
@PVince81
Copy link
Contributor

bisect might be possible if this worked in 9.1

@SamuAlfageme
Copy link

SamuAlfageme commented Aug 1, 2017

@PVince81 I can confirm listing the sessions used to work in 9.1 (tested in 9.1.3 and I used to get even cURL logins in the sessions table) - not revoking them though, maybe on a previous version the "Disconnect" button also worked for that.

I'd say increase severity here. There's some implications, specially in terms of revoking those sessions now that we're trying to get OAuth2 out of the oven and this might be important to get fixed.

EDIT: I can't actually make #24703 to work even in 9.1.0

This is also one of the causes behind #28553.

@PVince81 PVince81 added the p2-high Escalation, on top of current planning, release blocker label Aug 1, 2017
@felixboehm felixboehm modified the milestones: development, triage Aug 16, 2017
@PVince81 PVince81 assigned IljaN and unassigned DeepDiver1975 Aug 30, 2017
@PVince81
Copy link
Contributor

@IljaN please bisect this and fix if possible

@IljaN
Copy link
Member

IljaN commented Aug 31, 2017

d552f5f introduces the bug

@IljaN
Copy link
Member

IljaN commented Aug 31, 2017

There was a bug in my bisect script new potential candidate is f1dc2d9, need to analyze

@IljaN
Copy link
Member

IljaN commented Sep 1, 2017

Confirmed that f1dc2d9 is the offending commit by reintroducing the removed line

@PVince81 PVince81 modified the milestones: development, planned Sep 18, 2017
IljaN added a commit that referenced this issue Oct 11, 2017
Current token must be not null

Generate auth token for http_basic_auth logins

Cleanup
PVince81 pushed a commit that referenced this issue Nov 8, 2017
Current token must be not null

Generate auth token for http_basic_auth logins

Cleanup
PVince81 pushed a commit that referenced this issue Nov 10, 2017
Current token must be not null

Generate auth token for http_basic_auth logins

Cleanup
IljaN added a commit that referenced this issue Nov 10, 2017
Current token must be not null

Generate auth token for http_basic_auth logins

Cleanup

(cherry picked from commit 03b0bdb)
@PVince81
Copy link
Contributor

fixed through #28879

@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.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants