When is a distant user replicated locally?

Hi,

It is Bob again. I told you I was a bit puzzled about who could log into me: https://git.happy-dev.fr/startinblox/djangoldp-packages/djangoldp/issues/201

Let's suppose for a minute we answered that question, and that user Alicette can legitimately create an account on my server and login at my place. When does that process happen, and how? It is the client's job? It is mine?

I'd like to know better.

added Question label

Looks to me like an open question, you are not waiting for any proposals here, just asking how it works right ?

The ones to know about that are probably @bleme or @christophehenry if he had a chance to look at that. My 2 cents, I would guess that it's handled by djangoldp_account through the use of the LDPUser class.

@balessan What I want, is that it works on the FNK app. It is not the case at the moment. A user from collective A has not way to join a circle from collective B. We pinpointed the problem to be that we had no idea when and how a local version of the distant user should be created, hence this issue.

Don't hesitate to ask some more if I'm not being clear.

By Alexandre on 2020-01-15T17:44:52 (imported from GitLab project)

It is supposed to work, it has been developed. I suggest you call @bleme who has been working on this. He knows how it works.

Hello,

It's been a long time but in my mind a distant user is never really "replicated". What's should happen is that : when a user from a server A log to a server B, a 'local' account is created on server B but its only convenience. Server B should only use the user URL pointing on server A to identify the user.

So when is it happening ? It's happening when the user A try to do an action for the first time on server A. So he's authentified and the local account is created

By Jean-Baptiste on 2020-01-16T15:03:12 (imported from GitLab project)

it's created when you provide the site with a token it doesn't recognise startinblox/applications/sib-app#287 (comment 56199).. but it's stored on the username field which causes problems with the slug and causes the 500 linked in that issue

my hotfix on test-paris basically prevents it from (not) working https://git.happy-dev.fr/startinblox/applications/sib-app/issues/287#note_55824

there is an MR open for changing the behaviour to return 404 if the user wasn't recognised (https://git.happy-dev.fr/startinblox/djangoldp-packages/djangoldp-account/merge_requests/35) but following these discussions I think instead the id should be stored on a field that isn't username (https://git.happy-dev.fr/startinblox/djangoldp-packages/djangoldp/issues/201#note_58413).. what does everyone think?

@jbpasquier Does it answer your doubts in terms of UX?

By Alexandre on 2020-01-16T15:03:12 (imported from GitLab project)

I lack technical knowledge to have an opinion about which field is suited.

@bleme Do you remember why was username used? Do you understand the problem raised by @calummackervoy? Are they somewhat expected and do you have a suggested solution?

By Alexandre on 2020-01-16T15:05:04 (imported from GitLab project)

Isn't the slugification function the cause of the problem, rather than the fact that we use the userrname?

I thought about this but if I was going to use DjangoLDP on another application, I might also want to use the username in a slug (or have another use for a username which prevents a URL from being a valid username)

makes sense

mentioned in issue management/core-team#3

closed

changed milestone to %0.7