On Saturday, July 18, 2015 at 11:35:44 AM UTC-4, Iain Duncan wrote: > 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). >
Thanks! I bought fancy screen covers to handle that stuff. I'm just getting old, and the sinus infection tanked me. I love coffee too much to cut it out ;) > 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? > Yeah, that's the idea. It's pretty simple. I've recently implemented variants of this in a few ways. the one I've been most happy with so far is this: I used the `dogpile` caching system (which has a get_or_create fallback) that is backed by a local `redis` server. The middleware(though I used a tween) just uses the cached lookup function. on a hit, it pulls from redis (super fast); on a miss, it pulls from a local web service using the `requests` library, then populates the redis key. depending on whether or not that "application" has seen the user, we may touch the database as well to log it. the nice part of this, is that we rarely touch the database due to the caching, and many requests don't touch the database at all. I don't have any code I can share, and can't think of examples... but its pretty straightforward. i could probably slap together an example if you need it. -- 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 pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
