Ew, but if you need it you need it. Honestly it looks like a bug in threading that something public exposes _RLock.

Indeed 🤮😞 It's mostly a shutup-treat for mypy which for some reason rejects type(RLock()) as a type. This is the only workaround I found for a dynamic low-level type coming from a factory function RLock(). I'll try to dig a bit more, but my hopes are low.

Yissss 🐍 I fixed this with a little protocol instead.

Cool! Now I've actually seen Protocol in the wild, and it makes sense.

Not entirely sure I understand the purpose of "authoritative".

This is related to caching and thread safety, in the boundaries of the current design.

The "problem" is in the way how this whole authentication is performed in BaseView._is_authorized, which first creates the authenticator, __call__s it to get the Identity and only then it verifies the right permissions with Identity.is_authorized.

These two consecutive steps have no locks, so they can get mixed up with other threads simultaneously doing the same thing. Because I'm authorizing the user via GitHub API calls, my goal is to prevent those from repeating not only by caching that for some TTL, but also by blocking concurrent identical auth requests from different threads, so only a single thread gets to do the API calls and other just sit blocking and get only the result.

Because I wanted to do all the API calls within the GithubAuthenticator.__call__ method not to drag the requests Session object around (which is otherwise helpful in reusing a single TLS connection the to API), I'm storing only the resulting permissions on the GithubIdentity object, which can only simply expire.

in a different design with a shared requests.Session, the GithubIdentity would know itself how to get the user's permissions (and refresh its permission cache), but the Session should have a limited lifetime and as such, I'd have to manage it externally, which seemed even more complicated.

With all this, and the fact all the caches not only have configurable TTL, but also a rather low maximum size, I was obsessed about a scenario where (likely) an attacker would DoS the permission cache by doing concurrent calls for the same user, but different org/repo. In that scenario, the cached entry that got stored in the GithubAuthenticator.__call__ gets evicted sooner than it's being finally accessed via Identity.is_authorized.

Therefore I couldn't eventually resist to introduce a tiny in-between cache to remember the permissions for a user obtained in __call__ till it's being successfully read in is_authorized 😮‍💨

This permissions method is called in two contexts:

• in the __call__ to peek if a certain user's permissions are cached
• from is_authorized, which isn't used internally, but mean the obtained permissions have been read by the core logic for good and that I'm free to finally forget it.

The authoritative flag is just for that latter case, telling the logic the permissions have been properly read and now can sit and expire in the regular cache.

I admit this design is covering a really niche scenario, but once I realized it's there, my "OCD" couldn't let it stay. If you think there's a chance to considerably simplify the design, I'm all ears, but since this works and it's already done... 😇

That sounds good to me. My approach would just (if I'd noticed it at all, which I probably wouldn't because I wouldn't have tested high concurrency) have been to throw a mutex around the critical section and accept the performance hit. This seems much more amenable to many callers at once.