Hi Ekr, On 2020-07-28 15:54, Eric Rescorla wrote: > On Tue, Jul 28, 2020 at 6:45 AM Henrik Levkowetz <henrik@xxxxxxxxxxxxx> > wrote: > >> Hi Ekr, >> >> On 2020-07-28 13:54, Eric Rescorla wrote: >> > On Tue, Jul 28, 2020 at 4:43 AM Henrik Levkowetz <henrik@xxxxxxxxxxxxx> >> > wrote: >> > >> >> > The point being that these bespoke tools have a cost, not just in >> units >> >> of >> >> > dollars, but also in choice, reliability, etc. We should think hard >> >> about >> >> > what is so essential in our DNA that it merits all the costs. >> >> >> >> And base decisions and engineering on real data, instead of guesswork. >> >> >> > >> > I have no special insight in what is happening, but I would make two >> points: >> > >> > 1. A number of people are experiencing authorization failures (as Richard >> > reports) >> >> Yes, and all of them boil down to one issue: These are people who have >> multiple registrations (hackathon, remote) where they have used different >> email addresses for the different registrations, and there has been a >> difficulty connecting up the registration with the required 'remote' >> reg_type >> for WG/RG session participation with the datatracker login. >> > > Well, as I said, I have no special insight into what's going on here, but > why are these issues intermittent? For instance, it was failing for me > yesterday but works today, even though my configuration has not changed. Without more information and looking into what happened, I can of course not say why. However, when there has been issues of the kind I described above, the meetecho guys have messaged me, and I've sorted out the registrations. Improved code to deal with the human inconsistencies involved will be deployed later today. >> 2. For some reason, Meetecho seems to be re-contacting the datatracker >> > every time the user joins a new session rather than remembering that the >> > user is authenticated. This seems like it potentially exacerbates (1), >> >> This is as designed. Meetecho knows nothing about a new connection than >> what it gets from the datatracker, and arguably should not. If you want to >> change this, I think you'll need to re-design OpenID Connect. > > > Huh? The conventional approach would be for Meetecho to have a cookie which > it uses for authentication and only reach out to the datatracker when that > cookie expires. This is the case for practically every SSO-based service I > use regularly. That sounds reasonable, but there might be reasons at the MeetEcho end I'm not fully aware of, such as (but not limited to) the different roles the same person might have in the different sessions (chair vs. not chair, for instance). > Anyway, >> the load of the OpenID Connect queries is maybe one tenth of the remaining >> load at peak login, so why exactly is this an issue? >> > > It's not an issue of load but of how often the datatracker is in the > critical path. Specifically, if Meetecho cached authentication, then people > who had successfully logged in Monday would most likely not be experiencing > failures at the Meetecho/Datatracker interface, whatever the cause of those > failures. Agreed, FWIW. However, the issues we've had reported and investigated till now have consistently not been intermittent; once the underlying issue with registration inconsistencies has been resolved, it's stayed resolved. Henrik
Attachment:
signature.asc
Description: OpenPGP digital signature
