[Staging] 500 on https://api.test-paris.happy-dev.fr/users/

After having logged out and logged in again on staging, I get:

Access to fetch at 'https://api.test-paris.happy-dev.fr/users/' from origin 'https://test-paris.happy-dev.fr' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

changed milestone to %Circles

By Alexandre on 2019-11-12T16:36:06 (imported from GitLab project)

mentioned in merge request !77 (merged)

@jbpasquier, @christophehenry, @calummackervoy: I am still facing that problem.

By Alexandre on 2019-11-17T14:12:42 (imported from GitLab project)

For some reason I think this occurs when there is another serverside error.. do you have a 500 or something before it in the console/network? Or in the server logs?

@alexandre The error is not here anymore. Should this be closed?

By Christophe Henry on 2019-11-18T12:26:32 (imported from GitLab project)

I'm still getting this error

Right now I don't have it any more. I had when I reported the issue yesterday, and did clear my cache to no avail.

I close it for now, and will re-open if someone faces the issue again.

By Alexandre on 2019-11-18T23:01:05 (imported from GitLab project)

closed

By Alexandre on 2019-11-18T23:01:05 (imported from GitLab project)

reopened

By Alexandre on 2019-11-21T15:25:30 (imported from GitLab project)

I'm facing the problem again.

By Alexandre on 2019-11-21T15:25:37 (imported from GitLab project)

mentioned in merge request !80 (merged)

By Alexandre on 2019-11-21T21:56:14 (imported from GitLab project)

I'm getting it right now. I saw this on admin: https://api.test-paris.happy-dev.fr/admin/djangoldp_account/ldpuser/56/change/

I believe that it's the cause of the 500. Someone knows who/what/where it is?

Indeed. This was a user with username http://localhost:8000/users/admin/ and slug http://localhost:8000/users/admin/. The slug field is what caused the problem. This user got created somehow yesterday. Probably not using the Django admin (which had no history on that object).

The user has been deleted now. The page has returned to normal.

We have no clue as to how this particular user got created...

By Christophe Henry on 2019-11-22T14:53:53 (imported from GitLab project)

The problem is reproductible by creating a user in Django admin and then modify the DB by hand to put http://localhost:8000/users/admin/ in the user and slug fields. This causes the error:

NoReverseMatch at /users/
Reverse for 'ldpuser-detail' with keyword arguments '{'slug': 'http://localhost:8000/users/admin/'}' not found. 1 pattern(s) tried: ['users/(?P<slug>[\\w\\-\\.]+)/$']

which is the error that was logged on test-paris' server.

By Christophe Henry on 2019-11-22T15:00:42 (imported from GitLab project)

mentioned in issue #302 (closed)

By Christophe Henry on 2019-11-22T15:49:06 (imported from GitLab project)

This was caused by a bad record in the DB. Probably a smelly migration. See #302#note_54911.
I'm closing this. We'll reopen if this happens again.

By Christophe Henry on 2019-11-23T09:48:51 (imported from GitLab project)

closed

By Christophe Henry on 2019-11-22T15:50:41 (imported from GitLab project)

Shouldn't we handle the case to avoid the 500 error?

We're not guaranteed the users won't do anything silly.

It was probably caused using the CURL command that has been passed around to test federation.

By Alexandre on 2019-11-23T15:33:27 (imported from GitLab project)

reopened

By Alexandre on 2019-11-26T08:33:34 (imported from GitLab project)

@christophehenry, @jbpasquier: I have the issue again. What I can say is that for a brief moment it was working, I wrote 2 one-to-one messages and then that was over. There probably is something wrong with the generated notifications.

@matthieu might know something about it.

By Alexandre on 2019-11-26T08:36:00 (imported from GitLab project)

I can't see the notifications on test-paris, I get a 403 here: https://api.test-paris.happy-dev.fr/notifications/

I changed it on the admin, and here is what I see (which seems fine)

{
  "@id": "https://api.test-paris.happy-dev.fr/notifications/1/",
  "author": {
    "@id": "https://api.test-paris.happy-dev.fr/users/alex/"
  },
  "object": {
    "@id": "https://api.test-paris.happy-dev.fr/users/alex/"
  },
  "type": "Message",
  "summary": "Tu reçois ?",
  "date": "2019-11-26T08:29:37.939749Z",
  "unread": false,
  "user": {
    "@id": "https://api.test-paris.happy-dev.fr/users/matthieu/"
  },
  "permissions": [
    {
      "mode": {
        "@type": "view"
      }
    },
    {
      "mode": {
        "@type": "change"
      }
    },
    {
      "mode": {
        "@type": "control"
      }
    }
  ],
  "@context": "https://cdn.happy-dev.fr/owl/hdcontext.jsonld"
}

Maybe we need to check the server logs @jbpasquier ?

Pretty sure that have no link with notification.

Someone or something create an user with an unallowed username. We still need to find what/who/why.

For information, that one was created today at 08:30:52.

mentioned in issue #312 (closed)

Something is causing a new user to get POSTed with localhost:8000/users/admin/ (maybe to do with token from a local session?).. I think this can be 'fixed' by adding validation on usernames to make them valid for a URL

@calummackervoy: Are you able to implement that?

By Alexandre on 2019-11-29T15:36:47 (imported from GitLab project)

yeah sure :)

assigned to @calummackervoy and unassigned @christophehenry

the validation was actually already there but for some reason getting bypassed ...

In DjangoLDP_account I've updated LDPUser.save() to have the following check:

self.full_clean()

https://git.happy-dev.fr/startinblox/djangoldp-packages/djangoldp-account/blob/username-validation/djangoldp_account/models.py#L87

I've not opened this in an MR because it's bad practice to validate in the save().. but if we deploy DjangoLDP_account branch username-validation to test-paris then the next time this happens it should kick off and we'll have the log to see when the problem occurs @jbpasquier ?

Keep us posted

By Alexandre on 2019-12-02T10:15:59 (imported from GitLab project)

@calummackervoy On live on test-paris only. Will investigate the logs tomorrow & we'll see.

Cool. I tested it but so far the error is gone and I couldn't trigger it again. Let's see...

By Alexandre on 2019-12-02T13:35:51 (imported from GitLab project)

@jbpasquier sent me the logs from test-pairs and found how the bug is triggered

Internal Server Error: /check-user
Traceback (most recent call last):
...
File "./djangoldp_account/auth/backends.py", line 50, in authenticate
    user = Solid.get_or_create_user(userinfo, id_token['sub'])
...

https://git.happy-dev.fr/startinblox/djangoldp-packages/djangoldp-account/blob/master/djangoldp_account/auth/backends.py#L28

so what happens:

• someone is testing on their localhost, which they have a token for (127.0.0.1:8000/users/admin/)
• they change their config.json to point to test-paris
• the front-end tries to use the localhost token
• this calls Solid.get_or_create_user(userinfo, id_token['sub'])
• user 127.0.0.1:8000/users/admin/ doesn't exist (it's on the client's localhost), so it creates it

Why is this line get_or_create_user? Shouldn't it just be get_user, and if it can't then return 403?

@calummackervoy The reason is probably that if Paul from HD Toulouse accesses a resource from HD Paris, it will create a local user on Paris' server for Paul's user.

By Alexandre on 2019-12-03T15:50:25 (imported from GitLab project)

unassigned @calummackervoy

assigned to @jbpasquier

By Alexandre on 2019-12-03T17:05:46 (imported from GitLab project)

I guess it's not a solid auth issue. More a djangoldp one.

As we create on server side users when they don't exists, I believe something broke during the switch to urlid form.

@sylvain Do you agree with this? I'm not enough comfortable with this part of djangoldp to confirm this, more investigation may be needed here.

I'm not sure to understand what the problem is. I'm available tomorrow for a call if I can help.

@calummackervoy With your recent investigation, you may be more aware of the problem than me, could you handle a call with @sylvain to explain the situation?

Feel free to ask me if more details is needed to explain the track I hinted.

@calummackervoy happy to have a discussion about this if I can help

aye whenever's good for you :)

assigned to @christophehenry and unassigned @jbpasquier

@christophehenry please read my comment above (https://git.happy-dev.fr/startinblox/applications/sib-app/issues/287#note_56199) for context. Spoke to Sylvain about this and the conclusion is that authenticate shouldn't make the call Solid.get_or_create_user(userinfo, id_token['sub']), it should try to GET the user locally, and if it can't return 403

this will fix this issue, the linking data between servers is a separate concern

Alright. Nice work. Why are assigning this back to me? Do you need any help to solve it?

By Christophe Henry on 2019-12-04T17:10:38 (imported from GitLab project)

I guess you guys should call each other to see how to fix this. In any case, if you are to be in charge of DjangoLDP, I guess it's a good idea you get a good understanding of what the problem is.

I have a global understanding of it, but not into the details. But if that can help, don't hesitate to include me in the call.

assigned to @calummackervoy and unassigned @christophehenry

good point @christophehenry will need your help tho please :)

I've opened up an MR (https://git.happy-dev.fr/startinblox/djangoldp-packages/djangoldp-account/merge_requests/35) with some questions for you

Ok, I answered you questions. I'll review you MR until merged

By Christophe Henry on 2019-12-06T11:08:37 (imported from GitLab project)