Thank you Diez & Alessandro. I will look into the approach Alessandro suggested. In this approach the state-driven client would have to call /login?came_from=/api before attempting any other operation, which sounds okay. However, I suspect (correct me if I am wrong), if the session times out then the issue resurfaces. Speaking of which TG1.x had 'visit.xxx' config items, but TG2 does not (probably hidden in some repoze default config).
Thanks. On Nov 27, 11:36 am, Alessandro Molina <[email protected]> wrote: > On Wed, Nov 24, 2010 at 6:48 AM, ozwyzard <[email protected]> wrote: > > > When a user uses a typical browser to access a page that requires > > authentication, TG2 automatically responds with redirect to the login > > page (along with 'came_from 'parameter in the login url). > > > However, I have a scenario where a state-machine driven program > > accesses the same page, and expects an HTTP 401 response in order to > > retry with authentication credentials. > > You can also use the came_from parameter inside the post_login method > to change the behaviour. > > for example you can use: > > if came_from == '/api': > if not request.identity: > return 'FAILED > else: > return 'OK' > > instead of letting the code flow until the redirect. > Then your software can call /login?came_from=/api and check for > 'FAILED' to retry login. -- 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.
