Is this ticket worthy then? Even if the middleware is changed setting up the ajax_state view to behave properly I think should be an internal Satchmo change.
For now I have figured out how my lame work around would work. I will just turn off SSL globally and then turn it on for all the other checkout views manually, but that still isn't ideal. Let me know and I will create the ticket. On Nov 5, 10:46 am, Alex Robbins <[email protected]> wrote: > Satchmo has an SSL redirect middleware. If that is installed, I don't > think you'll be able to fix this with apache rules. Right now the > middleware lets you set SSL to be True or False. It seems like we > might need a third choice "maintain" or something like that. > Basically, let the connection stay on whatever protocol it is now. > > If we had a setting like that, and applied it to the ajax state view, > I think that'd solve this problem. > > Alex > > > > > > > > On Thu, Nov 4, 2010 at 9:52 PM, C <[email protected]> wrote: > > You need to track down what's doing the redirect. > > From there you need to break that redirect rule into two redirect > > rules. > > For a GET, let it just dump back a 302. > > For a POST, don't send back a 302, pass it through to the backend. > > Although in this case... anything allowed via http should be allowed > > through https. > > > I'll try and dig up the set of rules I kludged together for Apache > > running PHP through fastcgi tommorro. > > > On Nov 4, 11:29 am, amjoconn <[email protected]> wrote: > >> Morning, > > >> I have ran into some frustrating issues with the ajax state changer > >> not working in checkout. I think I know what is what the root cause > >> is and could use some help with working around it/fixing it. > > >> I first noticed the situation in production when I would change the > >> country and the ajax would start but everything would stay disabled. > >> The caused seemed to be /accounts/ajax_state wasn't returning > >> anything. > > >> Back on in my development environment everything was actually working > >> fine! I figuring it was https related. When I turned off SSL on > >> production it worked. What seems to be happening going > >> tohttps://domain/accounts/ajax_state/redirectstohttp://domain/accounts/ajax_state/ > >> and getting back the 302 is as far as the ajax request gets. Since > >> the response is blank this line in the javascript get executed: > > >> if (!result) { return; } > > >> And that mean the controls never get enabled. > > >> Turning off SSL just for the first checkout page is the fast work > >> around, even if it is undesirable. How do I do that quickly? I have > >> control in my payment module, but the checkout page is pre payment. I > >> imagine I need to put the right overriding url magic in my urls.py > > >> I am not sure what the better solution would be? Can you enforce the > >> protocol for ajax with out having to construct the entire domain? > >> Does doing an http ajax call that violate https security? Should > >> ajax_state simply respond even if it is requested over https? > > >> I look forward to what people with more experience have to say and > >> thanks in advance for your help. > > >> Albert O'Connor > >> albertoconnor.ca > > > -- > > 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 > > athttp://groups.google.com/group/satchmo-users?hl=en. -- 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.
