redirect_uri stored in cache and preventing the user to log again

Marie had this problem on Firefox that, on login she was automatically redirected to a cached redirect_uri. As that URI was not correct anymore, she was kind of trapped on this redirection loop.

I do not know how to reproduce the problem. I can't reproduce it now, but I just had it, Plup and Marie as well.

changed milestone to %Projects part I

By Alexandre on 2019-10-07T13:19:17 (imported from GitLab project)

mentioned in issue #232 (closed)

By Alexandre on 2019-10-14T10:23:58 (imported from GitLab project)

Do you think you can manage to have a try with Marie on private window on her browser?

I don't see why clearing cache isn't enough.

@jbpasquier : It does work well when using a private session. Plup and I also had the bug for the record.

By Alexandre on 2019-10-15T12:07:24 (imported from GitLab project)

assigned to @christophehenry and unassigned @jbpasquier

By Alexandre on 2019-10-16T21:34:53 (imported from GitLab project)

changed the description

By Alexandre on 2019-10-16T21:35:39 (imported from GitLab project)

@christophehenry : I think what needs to be done here is :

1. Understanding why we store that information in cache
2. Find a way to avoid those redirection loops, either by patching the lib, or clearing the cache on login/logout, what seems to make more sense

By Alexandre on 2019-10-17T11:28:26 (imported from GitLab project)

Clearing the cache on log-out seems a good practice. But I'm not sure it's enough. AFAIK, redirect_uri is only used during permission request. I don't see why it should be stored further.

By Christophe Henry on 2019-10-17T11:28:26 (imported from GitLab project)

Ok, so looking at the code, the Django OIDC lib is very agressive, checking that every field submitted for the provided client_id is correct. I don't know if this goes beyond OIDC spec of if the spec actually requires that every field is checked. I'll dig it.

Meanwhile, what I propose is — beyond erasing the cache after a logout — is erasing the cache when an error is met and start the process again. This could be a problem, though, since it may silence errors that are actually relevant.

By Christophe Henry on 2019-10-17T12:06:08 (imported from GitLab project)

But if an error is met, you're on a server page. So if you want to do it like that, you need to redirect to a script on client side. A bit weird.

If it's not used anywhere else, we can safely never stock it on cache?

The third-party library stores it on localStorage. It's not SIB code. Let me just patch the logout method first.

By Christophe Henry on 2019-10-17T12:13:39 (imported from GitLab project)

Alright, but you'll not have any logout option when this happen. Maybe, you should do it on login too.

Doing this on login will create a new client registration each time you login. Which is ok but a bit aggressive. As a patch, I'm ok with this solution.

By Christophe Henry on 2019-10-17T12:21:43 (imported from GitLab project)