I've been dealing with spats of SSL issues recently too. I eventually also settled on making Satchmo as ignorant as possible and performing rewriting on the server. In my opinion, this should become the standard methodology; the current internal method for handling SSL is pretty broken, as we can see by almost everyone in this thread admitting to just using the web server's rewrite to ensure the right mode is used.
Since I'm using basic PayPal, however, a redirect causes the loss of POSTed data, which means that Satchmo does not fully register a given sale. To work around this, I went into the lookup_url method and set ssl as always True (not default True, always True). I'm hoping that makes PayPal work correctly by avoiding the redirect that drops pp's post data, but I haven't tested because the test interface usually works, even without the post, but the real payments don't work; I'm assuming here because they don't have the POST attached. So hopefully that will fix that. There is really no need to be weird about this or handle it internally beyond URL writing; Satchmo should allow us to specify which links should be printed with https:// prefixes, and otherwise let us deal with things like redirecting on the web server. Since we currently have to eat the SSL variable to avoid errors or redirect loops if we are using web server rewriting/redirection, it does not get passed correctly to the application. There should be a global toggle that is respected regardless of anything else. -- You received this message because you are subscribed to the Google Groups "Satchmo users" 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/satchmo-users?hl=en.
