On Mon, Mar 3, 2008 at 6:26 PM, jostheim <[EMAIL PROTECTED]> wrote: > > Hi-
Hey! > I am trying to ensure that all login requests come through https url's > (are encrypted). I know I can edit the code in the login controller > to do this, but by the time we get there apparently work has already > happened (we have already logged in, identity always seems to be > set). I am assuming there is some kind of filter in front of all > requests that handles the login stuff and forwards to login. > > So I was wondering what is the best way to make sure that all login > requests are coming from ssl sources? Should I add another filter? > Is there a built in way to manage this? > > Once logged in the whole site will be open, before that only a few > pages (not behind identity management will be open). > > Ideas? Jeers? This is already implemented in the SVN and will be part of the next 1.0.4.4 release of tonight. The tg code was already in the 1.0.4.3 but the quickstart templates were a bit flaky: ~~~~~~~~~~~~~~~~~~ Added a new config option (app.cfg) which controls the kind of redirection the framework will raise in case of identity errors. By default TG used an internal CherryPy redirect in such cases. But the problem was that if you tried to use a failure url such as https://somewhere then CP raised a 404 error and that was all. Using this new system, you can activate _external_ redirects for identity errors by using the identity.force_external_redirect in app.cfg. This will permit redirecting your clients to any HTTPS url that is managed by an external apache or nginx rewrite rule. ~~~~~~~~~~~~~~~~~~ Your best bet is to grab the latest 1.0.4.4 release when it comes out (or svn but if comes out tonight) quickstart an SQLAlchemy project with identity: tg-admin quickstart -s -i -p forcesecure forcesecure and look into the login method and template for the changes you'll need to add to your existing project if you want to support thje force_https option. Please be aware that this parameter works with limitations: if you were submitting a form containing a FieldStorage this will fail because the force_https uses an external redirect that will automatically generate a get from your client and FieldStorage will not go through GET requests because of size... Appart from this special limitation all other use cases should be fine. Cheers, Florent. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
