Internal redirect?

[AFO]

Hello,

Is there a way to internally redirect to a different controller /
method?


- AF

[Rodney Haynie]

Hello AF.

from tg import redirect

Then from within one controller you can redirect to another.

...
redirect('another_controller')

Rodney

> - AF
>
> --
>
> You received this message because you are subscribed to the Google Groups "TurboGears" group.
> To post to this group, send email to turbo...@googlegroups.com.
> To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/turbogears?hl=.
>
>
>
>

[Raphael Slinckx]

I think that will trigger a 302 redirect, not an internal one.

[AFO]

On Nov 23, 5:28 am, Raphael Slinckx <rslin...@gmail.com> wrote:
> I think that will trigger a 302 redirect, not an internal one.
>

Exactly.... is there any way to do it internally?

[Diez B. Roggisch]

No. I've written such thing as part of my tgext.simpleauth, a
repoze.w*-replacement.

http://bitbucket.org/deets/tgextsimpleauthorization/

It is coneceived as middlewar, and you can perform internal and external
redirects.

However, I would advise in general *against* internal redirects, because you
might mess up the WSGI-environ when doing so.

Diez

[AFO]

> > > I think that will trigger a 302 redirect, not an internal one.
>
> > Exactly.... is there any way to do it internally?
>
> No. I've written such thing as part of my tgext.simpleauth, a
> repoze.w*-replacement.
>
> http://bitbucket.org/deets/tgextsimpleauthorization/
>
> It is coneceived as middlewar, and you can perform internal and external
> redirects.
>
> However, I would advise in general *against* internal redirects, because you
> might mess up the WSGI-environ when doing so.
>

How does telling the TG2 dispatch code to simply start processing with
a different exposed() method mess with the WSGI-environ? (Unless it's
emulating a real 302 that just never get back to the client...?)

[Diez B. Roggisch]

The WSGI-stack passes down an environment. This might get modified, for
whatever purposes. E.g. you can alter header-values to force Pylons to
deliver i18n'd messages with a user-defined language instead of browser-based
one. You can stick values in there like identities or other objects.

Now bouncing back a redirect to a specific middlewar that then dispatches
again, this will of course *not* undo changes that have been made before.

This *can* cause havoc. It might be that some middleware makes assumptions
about certain things in the environ that because of this bouncing back and
forth are messed up.

I don't say it has to happen. It *could* happen, and lead to hard to debug
problems because your request-flow gets increasingly complex.

So just using a 302 is the safer alternative, unless you have good reasons not
to do that and are prepared to possibly sanitize your environment.

Diez

[AFO]

At the WSGI level I can certainly see the redirect being an issue.

But, I was referring strictly within TG2. Or, are all TG2 controller
methods actual distinct WSGI entities?

[Diez B. Roggisch]

>
> At the WSGI level I can certainly see the redirect being an issue.
>
> But, I was referring strictly within TG2. Or, are all TG2 controller
> methods actual distinct WSGI entities?

No, but the whole dispatch and everything is based upon the request being a
thin layer over the WSGI-environ.

Diez

[AF]

OH... Ok.

thanks