Thanks Diez. I'll take a longer look at it but at first glance, it looks really good. My only question would be how to make it play nice with the existing repoze + TG integration so that HTML UI predicates behave as normal....in my 1 minute glance at your code it looks as though you're stripping-out the existing repoze stuff completely when building up the WSGI app stack, no?
If my assessment is correct, any ideas how one might go down that path? On Apr 27, 10:33 am, "Diez B. Roggisch" <[email protected]> wrote: > Am 27.04.2010 um 15:48 schrieb robneville73: > > > > > > > I'm working on a TG 2.0 project ATM where we are trying to support > > both a standard HTML-based UI and an API to a flash client via JSON. > > So far things are going well, but I'm frankly struggling with > > authentication. > > > Here's the situation. I want to be able to put a repoze predicate on a > > controller method as normal and have the behavior differ depending on > > where the request came from. Specifically, I don't want the server to > > return a redirect 302 when the request has come from my API client and > > the session isn't authenticated, instead, I want the unmolested 401 to > > be returned. Conversely, when the request comes from a browser, I do > > want the default repoze challenger mechanism to redirect me to the > > login form. I'm running into a brick wall trying to understand the > > various project documentations and browsing the source code of those > > projects to understand how I might do that. > > > For other reasons, I've already written some WSGI middleware to > > distinguish an API request from a normal one, so I have a way of > > detecting that in the WSGI environment if that helps. Additionally, I > > have figured out that adding: > > basic_auth = BasicAuthPlugin('myapp') > > base_config.sa_auth.identifiers = [('basic_auth',basic_auth)] > > allows me to send HTTP authentication info in headers coming from the > > API requests and it appears to be authenticating me. > > > It seems to me that the answer either lies in deciphering repoze's > > request classifier mechanism for which I've found no good examples of > > it's use for my purposes, or in perhaps creating my own decorator > > (i.e. something similar to @require) that I use on wrapped controller > > methods that only the API client uses - although this solution is less > > than ideal. > > > I have a feeling that there's an already existing, elegant solution to > > this but I'm not finding it. HELP PLEASE! > > It's not released, but we use it in producetion - my replacement for > the whole repoze.w* stack. Because I couldn't work with it. > > http://bitbucket.org/deets/tgextsimpleauthorization > > The sole reason it's not released is the lack of docs. I started, but > never finished. > > If you want to give it a shot, I'm happy to help. Maybe that gives me > the push to finally release it. > > Diez > > -- > You received this message because you are subscribed to the Google Groups > "TurboGears" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/turbogears?hl=en. -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
