Thanks Jonathan
> Sorry, I've had a migraine and eye-strain all week and can't seem to > phrase questions (or anything) right. > > Off topic: have you tried the new glass for your glasses that changes the colour balance to reduce eye strain? I used to get very frequent migraines from coding, and an updated prescription with the the new fancy glass *really* helped. So worth the extra $200 or whatever it was. (Reducing daily caffeine also helped, FWIW). I could be interpreting this all wrong and what follows will possibly not > make much sense, but here goes... > > It sounds like you're thinking about a shared library/mechanism for all > the apps to set up ACL's using a centralized auth database. > > If that's the case, my initial reaction would be to divorce the Auth DB > from the equation and instead of a "shared auth" look towards a > "centralized" auth. Having a lot of services depend on a single DB can > lead to bottlenecks. I would look into a way of implementing more of a > standalone auth service (e.g. Service Oriented Architecture) which is the > only thing that actually talks to the DB and that performs it's own caching > of the ACL data. Your apps never talk to the DB about auth, but instead to > this service (via web requests, messaging, etc). The auth service can > optimize db access and cache data (for example 10 minutes); meanwhile each > of the micro-apps has a local cache for the data as well (for example 1 > minute). This way your apps all just talk to a single service instead of > touching the DB. Then you have a shared python library as a > middleware/tween/etc that handles talking to the auth service and locally > caching data... but the only DB that these apps know about is their own > DB... everything they know about from the auth service is just JSON (or > another simple format). > > You might be thinking of something like this already. If not, I'd suggest > considering it. It's basically in the same vein as how apps that use oAuth > / JWT operate -- everything is completely separate. > Thanks a lot, that's helpful. I guess I had been thinking that each app would have middleware that dealt with determining who they are from the session cookie, and that this middleware would be the only thing that looked at auth tables. From then on, they would only be using identity related variables (id, groups) in the WSGI env, much as repoze.who does (i think?). But I guess you're saying instead of having db lookup in the middleware, they would talk to a service, is that correct? How is this done on a low level? Do you know of any examples I could look at? iain -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
