Ios: Fix used/stored user ID

[mario]

We use the username for various things - search, favorites, and stuff like that. Unfortunately internally what you log in with is not what you should use in those queries. To make things simpler, we should always use the "internal" ID. This is to be fixed in the following way, and as soon as possible:

Two use-cases:

1) open an app with accounts already in
Steps:

• poke /ocs/v2.php/cloud/user for each of the accounts on startup (show some kind of "Migration" screen, maybe with a simple loader)
• replace stored username with "id" value found here:
  https://usercontent.irccloud-cdn.com/file/8L6mFbyc/Bildschirmfoto%202017-08-02%20um%2009.02.00.png

Make sure if this procedure fails for any account, that it's repeated properly.

2) open an app with no accounts

• once you log-in, if success, poke /ocs/v2.php/cloud/user and store "id" as username
• only then proceed

@marinofaggiana please treat this as a priority. Thank you.

Fixing this will fix several other issues mentioned in the bug tracker.

[marinofaggiana]

@mario what's the difference from username and id on /ocs/v2.php/cloud/user ?

[mario]

@marinofaggiana I don't see the "username" in the output on the screenshot?

Basically, you currently store whatever the user put in the username field which is wrong. We need to store the ID that we get from this endpoint IF authentication is successful, and use that for all requests.

[marinofaggiana]

no no @mario my question is not in the screenshot but in general ... when or why ? the username is different from id ?

[mario]

Yes, you can login with various things, but only ID is the right thing to use for queries. Always - search, favorites, dav, etc.

[marinofaggiana]

ok, but I must to keep the username for example change the password or I must always use only ID (rewrite username to id on Database) ?

[mario]

ID should be good enough (rewrite username to id in database). There are two different use cases, and I've explained both in the initial issue.

[marinofaggiana]

ok.

[marinofaggiana]

p.s.the api user is available for all version of NC ?

[mario]

Should be from NC 9, so yes. Confirm @MorrisJobke or @schiessle? :)

[marinofaggiana]

Ok, this fix is simply .. I already use /ocs/v2.php/cloud/user

[mario]

OK, please open a PR for this fix so I can review before we commit.

[MorrisJobke]

Should be from NC 9, so yes. Confirm @MorrisJobke or @schiessle? :)

Correct. There since ages 😉 And the id is the userid (that's how it is named in our DB). The username or loginname could be different. With LDAP vor example the admin can specify multiple attributes like FN - full name (like marino.faggiana) and email (like [email protected]) being valid login names. They all then map to the userID, which in the case of LDAP is by default the UUID (like 123456-1234-asdf-qwertz). Also normal users can login with userID or email and their password. Then you also need to fetch the userID. You then also can go just for using userID:password and drop completely the login name, because it could change over time (for example the user changes his email). The userID on the other hand will never change.

Is this now a bit more clear to everybody? If not: ask :)

[marinofaggiana]

Aaaaa now is clear the bug ! Thanks @MorrisJobke

[marinofaggiana]

But if with LDAP is 123456-1234-asdf-qwertz I don't rewrite in my DB the username ... this is dangerous for the change password .... can I use username 123456-1234-asdf-qwertz with passwd : newpasswd ? mmmm I want to think about it

[MorrisJobke]

But if with LDAP is 123456-1234-asdf-qwertz I don't rewrite in my DB the username ... this is dangerous for the change password .... can I use username 123456-1234-asdf-qwertz with passwd : newpasswd ? mmmm I want to think about it

What do you mean? That was just an example. It's best to store the userID, because this will never change (it's our internal ID and can't be updated).

[rullzer]

@MorrisJobke I think @marinofaggiana is asking if he can use the internal id as username to login.

[marinofaggiana]

Yes but in my DB now exists username and I don't want replace the value with userID ... the username is the human name for the view but userID can't be a human name but a true ID as 123456-1234-asdf-qwertz.

[marinofaggiana]

Example Username : marino.faggiana but ID : 123456-1234-asdf-qwertz

[MorrisJobke]

Example Username : marino.faggiana but ID : 123456-1234-asdf-qwertz

But the username is more like the display name. That is what is shown in the UI (also on the server) - we only fall back to the userID if there is no display name. For login: there could be multiple options how to login, but we never show it how a user has logged in, because sometimes (for SAML) there is no login name, because it's basically only the userID, that is handed over.

And where do you get the username from?

[marinofaggiana]

And where do you get the username from?

username = userID

[marinofaggiana]

This is the modify @mario :

• add on tableAccount new var username

case 1 : (open an app with accounts already in)

After poke /ocs/v2.php/cloud/user

• if tableAccount.username is empty copy tableAccount.user to tableAccount.username (keep the username)
• copy ID from /ocs/v2.php/cloud/user to tableAccount.user

case 2 : (no account)

• after login poke /ocs/v2.php/cloud/user, if ok, copy ID to tableAccount.user, dismiss view and proceed else do not dismiss, present error and do not proceed

In all cases I keep the (old) tableAccount.username.

(now used only for view change password) but the App use only the tableAccount.user = ID

done.

[mario]

If this is what you prefer, sure. As long as it works :P

[mario]

Let me know when this is tested & released.

[marinofaggiana]

For me it's ok, @MorrisJobke exists a server for tested (where ID != username) ?

[mario]

@marinofaggiana you could easily test it this way:

setup an user account
assign an email to this
use the email address + password instead of username + password to log in into the Android app
💥

[marinofaggiana]

@MorrisJobke if you can tested with beta 2.17.6.00005. THX

[MorrisJobke]

@MorrisJobke if you can tested with beta 2.17.6.00005. THX

Let me check.

[mario]

@MorrisJobke did you test this? :)

[MorrisJobke]

I can't login at all:

The webdav request seems to work, but then it tries to use the email address as username and fails of course:

10.0.3.2 - [email protected] [07/Aug/2017:10:43:33 -0500] "HEAD /server/remote.php/webdav HTTP/1.1" 200 1188 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.17.6" 463692
10.0.3.2 - [email protected] [07/Aug/2017:10:43:34 -0500] "GET /server/ocs/v1.php/cloud/users/hey%40morrisjobke.de?format=json HTTP/1.1" 200 1393 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.17.6" 364697

The nextcloud log looks like this:

{"reqId":"z9yzOTL1yGH0cBsv5Tfo","level":2,"time":"2017-08-07T15:43:33+00:00","remoteAddr":"10.0.3.2","user":"--","app":"core","method":"HEAD","url":"\/server\/remote.php\/webdav","message":"Login failed: '[email protected]' (Remote IP: '10.0.3.2')","userAgent":"Mozilla\/5.0 (iOS) Nextcloud-iOS\/2.17.6","version":"12.0.1.5"}
{"reqId":"KzovVywxMSq1VAV2AqdK","level":2,"time":"2017-08-07T15:43:34+00:00","remoteAddr":"10.0.3.2","user":"--","app":"core","method":"GET","url":"\/server\/ocs\/v1.php\/cloud\/users\/hey%40morrisjobke.de?format=json","message":"Login failed: '[email protected]' (Remote IP: '10.0.3.2')","userAgent":"Mozilla\/5.0 (iOS) Nextcloud-iOS\/2.17.6","version":"12.0.1.5"}

[marinofaggiana]

Why ?

 GET /ocs/v1.php/cloud/users/m.faggiana%40twsweb.it?format=json HTTP/1.1

Response :

{ "ocs": { "meta": { "status": "failure", "statuscode": 998, "message": "The requested user could not be found", "totalitems": "", "itemsperpage": "" }, "data": [] } }

[MorrisJobke]

Why ?

Correct. The email is not a valid user. The username needs to be fetched first by a call to /ocs/v1.php/cloud/user AFAIK - right @rullzer ?

[marinofaggiana]

I don't understand , GET /ocs/v1.php/cloud/users/m.faggiana%40twsweb.it?format=json HTTP/1.1
return first err 998 and then 200 ... this break my procedure

[marinofaggiana]

And I have tested with old NC Server Nextcloud 11.0.0 (stable) but do not exists the ID ??
Who decided on this fix? for me this fix increments the issue ... @mario @MorrisJobke

ser Profile : {
    ocs =     {
        data =         {
            displayname = ncadmin;
            email = "<null>";
            enabled = true;
            quota =             {
                free = 1071600821;
                quota = 1073741824;
                relative = "0.2";
                total = 1073741824;
                used = 2141003;
            };
        };
        meta =         {
            itemsperpage = "";
            message = OK;
            status = ok;
            statuscode = 100;
            totalitems = "";
        };
    };
}

[MorrisJobke]

@marinofaggiana But this could also not have worked before? How is this handled currently if a user logs in via email?

[marinofaggiana]

I don't have nothing issue for this, nothing, the user use the user account not email ... But if this has to work this is not a correct way ... if the user use email the /ocs/v1.php/cloud/users/m.faggiana%40twsweb.it?format=json HTTP/1.1 response with error

[MorrisJobke]

I don't have nothing issue for this, nothing, the user use the user account not email

Ah okay - so it just didn't happen yet. Then see this as a bug prevention. 😉

But if this has to work this is not a correct way

We support it in the web UI - so we should also allow this in the mobile apps.

[marinofaggiana]

Sure ! @rullzer ping

[mario]

@marinofaggiana why do you use v1 and not v2? o.o

[marinofaggiana]

?? @mario i have only this :

#define k_url_acces_remote_userprofile_api @"ocs/v1.php/cloud/users/"

[mario]

I told you to use this: /ocs/v2.php/cloud/user @marinofaggiana

[mario]

This is the EXACT url you have to use (no additions)

[marinofaggiana]

Thanks @mario

[marinofaggiana]

@MorrisJobke fix build 00006

[MorrisJobke]

@MorrisJobke fix build 00006

Works, but there was one request with the wrong ID:

10.0.3.2 - [email protected] [09/Aug/2017:07:16:25 -0500] "REPORT /server/remote.php/dav/files/EMAIL HTTP/1.1" 404 1458 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.17.6" 455112

Maybe you can find the problem. Beside that it works 👍

[marinofaggiana]

Works, but there was one request with the wrong ID:

It's before the new build ?

[MorrisJobke]

It's before the new build ?

Nope - with the newest version from test flight (the version 5 minutes before my comment)

[marinofaggiana]

@mario the query for (e.g.) SEARCH and FAVORITE required username not userID ...

[MorrisJobke]

@mario the query for (e.g.) SEARCH and FAVORITE required username not userID ...

There is no difference in that. Just to be clear: we refer to the user ID as username as well. There is only this additional "login name" which is not used anywhere else except for the initial login to make it easier for the user. Beside that everywhere the username (== userID) needs to be used.

[marinofaggiana]

There is no difference in that. Just to be clear: we refer to the user ID as username as well. There is only this additional "login name" which is not used anywhere else except for the initial login to make it easier for the user. Beside that everywhere the username (== userID) needs to be used.

And why

10.0.3.2 - [email protected] [09/Aug/2017:07:16:25 -0500] "REPORT /server/remote.php/dav/files/EMAIL HTTP/1.1" 404 1458 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.17.6" 455112

I use REPORT remote.php/dav/files/user/path-to-folder ... try with SEARCH, it's ok or return a error ?

[MorrisJobke]

And why

Why what? the username there should be the userID and not the email address. Same goes for SEARCH.

[marinofaggiana]

I use userID ...now I use only userID for all ...

[marinofaggiana]

@MorrisJobke can u make a test if SEARCH works ? thanks

[MorrisJobke]

@MorrisJobke can u make a test if SEARCH works ? thanks

Tested and works 👍

10.0.3.2 - [email protected] [11/Aug/2017:08:08:51 -0500] "HEAD /server/remote.php/webdav HTTP/1.1" 200 1188 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.17.6" 1612572
10.0.3.2 - [email protected] [11/Aug/2017:08:08:52 -0500] "GET /server/ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1543 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.17.6" 510042
10.0.3.2 - test [11/Aug/2017:08:08:54 -0500] "PROPFIND /server/remote.php/webdav/Photos HTTP/1.1" 404 1505 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.17.6" 310360
10.0.3.2 - test [11/Aug/2017:08:08:54 -0500] "PROPFIND /server/remote.php/webdav HTTP/1.1" 207 2003 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.17.6" 338499
...

🚀 Thanks

[marinofaggiana]

Thanks @MorrisJobke

[tri2000]

after updating to this version of the client, accessing a file with the ios client prompts authentication/login, password is then entered, file/folder listing is then displayed, the prompt for login appears again... ...this continues to happen until the app is closed... also, the uuid is displayed as the user instead of the username

[MorrisJobke]

The UUID is the username. We only have a separate login name, but this is only there for the actual login and nowhere else used. Everywhere else the display name should be shown

[tri2000]

We are still seeing the issue of being prompted for a login each time a
file is opened. The prompt never works. We are also seeing where the app
crashes after those failed login attempts.

On Mon, Sep 4, 2017 at 1:32 AM, Morris Jobke [e-mail]
wrote:

The UUID is the username. We only have a separate login name, but this is
only there for the actual login and nowhere else used. Everywhere else the
display name should be shown

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/ios/issues/331#issuecomment-326877105, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AX8h0Kq4j0qdgjquKg_HpfHwXQR4Qa5Zks5se5mbgaJpZM4OrYRL
.

--
Success is the progressive realization of a worthy goal or ideal.- Earl
Nightingale

[mario]

Ah, so we basically need to store both userID and username. Username for login, userID for everything else.

cc @marinofaggiana for iOS implementation
cc @AndyScherzinger and @tobiasKaminsky for upgrading us to accountManager level 3 :D

[mario]

If this is indeed the case ... guess we'd need to test search/favorite/etc with LDAP, regular login, etc.

[marinofaggiana]

This is not clear, and dangerous :

1) UserID where used ? and why ?
2) username where used ? and why ?

fortunately I have username and userID. Now several user are blocked, @mario and @MorrisJobke please more info before make a significative modify.

[MorrisJobke]

UserID where used ? and why ?
username where used ? and why ?

As already explained a lot of times: we only have one way to refer to a user. Usually this is named userID, but you can name it however you want. This one is returned when you open ocs/v1.php/cloud/user with the credentials you got. Use then this userID everywhere.

[marinofaggiana]

And why several user do not send/receive/favorite files ... it's a bud configuration of server ? (LDAP ... ?)

[MorrisJobke]

Ah, so we basically need to store both userID and username. Username for login, userID for everything else.

usually you can login with the userID and the password. Additionally we also offer different other login credentials:

• the email address instead of the userID if the email address is unique in the system
• any LDAP attribute that is configured by the Nextcloud admin in the user_ldap app (could be CN -something like max.mustermann, email, first name, ...)

If there should be shown something in the app, that refers to the user: use the display name, that Nextcloud provides, because this is the user readable representation of the user and has no limitation to specific characters or spaces or so. This display name can only be used as human readable element and not to authenticate a user.

Theoretically there could be following setup:

user 1:

• userID: jan
• displayname: max
• email: [email protected]

user 2:

• userID: max
• displayname: john
• email: [email protected]

Then following will be allowed as login credentials: jan:PASSWORDOFUSER1 and [email protected]:PASSWORDOFUSER1 as well as max:PASSWORDOFUSER2 and [email protected]:PASSWORDOFUSER2. (Beware: max:PASSWORDOFUSER1 will never login user1) Those two users should be shown as max and john (display names) in the apps UI nevertheless and ideally the userIDs jan and max should never appear anywhere (in the webUI they also don't appear).

[tri2000]

I believe I understand what is trying to happen with authentication, but we
are still seeing the app start asking to re-enter the password after trying
to access a file using the app. It doesn't matter what we do, we are still
see it continue to prompt for a password until the app eventually crashes.

On Mon, Sep 4, 2017 at 10:24 AM, Morris Jobke [e-mail]
wrote:

Ah, so we basically need to store both userID and username. Username for
login, userID for everything else.

usually you can login with the userID and the password. Additionally we
also offer different other login credentials:

• the email address instead of the userID if the email address is
  unique in the system
• any LDAP attribute that is configured by the Nextcloud admin in the
  user_ldap app (could be CN -something like max.mustermann, email, first
  name, ...)

If there should be shown something in the app, that refers to the user:
use the display name, that Nextcloud provides, because this is the user
readable representation of the user and has no limitation to specific
characters or spaces or so. This display name can only be used as human
readable element and not to authenticate a user.

Theoretically there could be following setup:

user 1:

• userID: jan
• displayname: max
• email: [email protected]

user 2:

• userID: max
• displayname: john
• email: [email protected]

Then following will be allowed as login credentials: jan:PASSWORDOFUSER1
and [email protected]:PASSWORDOFUSER1 as well as max:PASSWORDOFUSER2 and
[email protected]:PASSWORDOFUSER2. (Beware: max:PASSWORDOFUSER1 will
never login user1) Those two users should be shown as max and john (display
names) in the apps UI nevertheless and ideally the userIDs jan and max
should never appear anywhere (in the webUI they also don't appear).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/ios/issues/331#issuecomment-326987342, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AX8h0DgTaTrv67apzI_7Dnwj1HLFaCj_ks5sfBYzgaJpZM4OrYRL
.

--
Success is the progressive realization of a worthy goal or ideal.- Earl
Nightingale

[tri2000]

We are seeing "no user given for the available login name..." seems the
UUID with the correct password is the problem.

On Mon, Sep 4, 2017 at 7:40 PM, Kenneth Machen [e-mail]
wrote:

I believe I understand what is trying to happen with authentication, but
we are still seeing the app start asking to re-enter the password after
trying to access a file using the app. It doesn't matter what we do, we are
still see it continue to prompt for a password until the app eventually
crashes.

On Mon, Sep 4, 2017 at 10:24 AM, Morris Jobke [e-mail]
wrote:

Ah, so we basically need to store both userID and username. Username for
login, userID for everything else.

usually you can login with the userID and the password. Additionally we
also offer different other login credentials:

• the email address instead of the userID if the email address is
  unique in the system
• any LDAP attribute that is configured by the Nextcloud admin in the
  user_ldap app (could be CN -something like max.mustermann, email, first
  name, ...)

If there should be shown something in the app, that refers to the user:
use the display name, that Nextcloud provides, because this is the user
readable representation of the user and has no limitation to specific
characters or spaces or so. This display name can only be used as human
readable element and not to authenticate a user.

Theoretically there could be following setup:

user 1:

• userID: jan
• displayname: max
• email: [email protected]

user 2:

• userID: max
• displayname: john
• email: [email protected]

Then following will be allowed as login credentials: jan:PASSWORDOFUSER1
and [email protected]:PASSWORDOFUSER1 as well as max:PASSWORDOFUSER2 and
[email protected]:PASSWORDOFUSER2. (Beware: max:PASSWORDOFUSER1 will
never login user1) Those two users should be shown as max and john (display
names) in the apps UI nevertheless and ideally the userIDs jan and max
should never appear anywhere (in the webUI they also don't appear).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/ios/issues/331#issuecomment-326987342, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AX8h0DgTaTrv67apzI_7Dnwj1HLFaCj_ks5sfBYzgaJpZM4OrYRL
.

--
Success is the progressive realization of a worthy goal or ideal.- Earl
Nightingale

--
Success is the progressive realization of a worthy goal or ideal.- Earl
Nightingale

[tobiasKaminsky]

Are there test credentials for a non-working android login?
I debugged it and for ldap and new login flow (>=NC12) we rely on the user we get back from weblogin flow and this is the userID.
Older accounts we do an upgrade and fetch the userID.

[blizzz]

usually you can login with the userID and the password. Additionally we also offer different other login credentials:

This is not exactly precise. I use to refer to the string you login with as "loginname". Various login names are possible per user. For local users, it is a case-insensitive userID, plus the emaill.

For LDAP, usually it is not possible to login with the UserID, which is by default generated from an LDAP entry UUID (aka GUID) by default. Typically, LDAP users log in with their LDAP username, and/or email address, and/or any other attribute (like Morris said), even the Car Licence Plate, for example (or an employee number as different, boring, more realistic example).

Just to be more precise, otherwise he is right. Loginname for authentication, User Displayname for presentation, UserID otherwise.

[blizzz]

Are there test credentials for a non-working android login?
I debugged it and for ldap and new login flow (>=NC12) we rely on the user we get back from weblogin flow and this is the userID.
Older accounts we do an upgrade and fetch the userID.

This is the correct approach, 👍

[MorrisJobke]

For LDAP, usually it is not possible to login with the UserID, which is by default generated from an LDAP entry UUID (aka GUID) by default. Typically, LDAP users log in with their LDAP username, and/or email address, and/or any other attribute (like Morris said), even the Car Licence Plate, for example (or an employee number as different, boring, more realistic example).

Didn't know that. Because this is maybe then the problem. If you use the userID to authenticate, it will break of course.

Sorry - I didn't knew that the user ID doesn't work in case LDAP is used. Is there any reason why it is that way? Because now you need to store the credentials (loginname + password for authentication) and the userID (for API stuff).

[blizzz]

Sorry - I didn't knew that the user ID doesn't work in case LDAP is used. Is there any reason why it is that way? Because now you need to store the credentials (loginname + password for authentication) and the userID (for API stuff).

Not now, since always™️.

The process is simply: you provide the login name, query LDAP, and you'll have a user record you can attempt to bind with (using the password) or not.

We cannot do this reliably with the userId, because of several reasons:

• we cannot use the login filter, because the attribute is not defined in it
• on AD it is a binary string and the value would need to be encoded again (fights including the attribute in the filter)
• the userID does not necessarily match with the attribute value (sanitized for not allowed characters, possible additional number to avoid name collisions)

It can be done differently by reading the DN from the mappings table and acting with the DN. However, it would circumvent the login filter and allow users who have been blocked by the filter rule to login again. Checking this means parsing the login filter to figure out the allowed login attributes, read them from LDAP, and request another check. This will make the routine more complex again with more code paths.

[marinofaggiana]

and now ?

[mario]

Use whatever user enters as login credentials, and for API use user ID? That should work afaik ... But please TEST favorites, search and all other functionality.

[MorrisJobke]

Use whatever user enters as login credentials, and for API use user ID? That should work afaik ... But please TEST favorites, search and all other functionality.

Yes - this makes sense. 👍

[marinofaggiana]

I rollback to old authentication.

[mario]

That will break other things. But meh... Morris or someone else will handle
this

On Thu, 7 Sep 2017 at 10:15, Marino Faggiana [e-mail]
wrote:

I rollback to old authentication.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/ios/issues/331#issuecomment-327725586, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAWsguMC-lcgWOrCullZwktW8s2Ih8Jks5sf6Y9gaJpZM4OrYRL
.

[marinofaggiana]

Yes Mario but I have too many email

[ghost]

Mariono, what is you email?

[marinofaggiana]

Ios(at)nextcloud.com