SSL and MEDIA_URL

[Bruce Kroeze]

I'm thinking about how to smoothly handle SSL-enabled pages.  We're most of the way there, but there's one remaining problem.  What about the MEDIA_URL?

If we just use the existing MEDIA_URL, then we'll be pulling in images from an insecure site, and the browser will give a warning about mixed secure-insecure.

I think one reasonable approach would be as follows:

1) Add a new setting, "MEDIA_SECURE_URL", which would point to the proper SSL enabled url

2) In satchmo.shop.context_processors.settings , use request.is_secure() to determine whether to return the normal or secure url as "media_url"

3) If secure,

3b) if there is a settings.MEDIA_SECURE_URL, use it

3c) else (for backward compatibility and ease-of-config), use the normal MEDIA_URL with https substitued for http.  If there was no "http" specified in the url, then use it unmodified

If this is handled somewhere else in Django, or there is a pre-existing standard solution, please let me know.  I looked but couldn't find anything.  I hate to look like an idiot, since it seems like a common case which would be fixed by now (with Django itself) but this really does seem to be something we need to do ourselves.

(Posting this to satchmo-users rather than developers for the widest exposure and thus chance that I'll be shown the standard way to do this.)

+Bruce Kroeze

[Chris Moffitt]

Bruce,

I took a little bit of a look at this and couldn't find any better alternative than what you're proposing.  We could cross-post this to Django-users just to double check if others are seeing this and have another solution.

-Chris

[Bruce Kroeze]

Also, there is the same problem with the Google tags.  They need to call an https address if the page is secure.  I've got that fixed already, but not committed until I resolve what to do with images. 

The harder one will be the thumbnailing code.  I'm tempted to say "why would you need a thumbnail on a secure page?" but then I realized that it is inevitable that *someone* will.  So we'll need to go test request.is_secure inside the thumbnailing code.

It is not really that fun (or pretty) to do, but it is necessary in order to avoid the mixed-secure warnings.  For good reasons, browsers are really picky about that.

+Bruce Kroeze

[Bruce Kroeze]

I fixed this issue tonight, using the technique I described above.

It works perfectly, and while I was at it, I fixed the google tags to use the proper secure connection when the page is secure.

Lastly, because I wanted to get this important fix in sooner rather than later, I committed my Google Adwords tags.  They were in the same file as the other google fixes, and I didn't want to take the time to strip them out and retest before committing.  As a result, we now have Google analytics tags for page tracking, sales conversion and signup conversion (new), Adwords sales conversion (new), and Adwords signup conversion (new).

Important:  To activate the secure-aware version of the google tracking tag, you need to change your analytics call from {% show_tracker %} to {% show_tracker is_secure %}.  It will not blow up if you don't do this, it will just not be aware of whether the page is secure. I've already done this in the store templates.

[Chris Moffitt]

Thanks for the fixes and further google integration.  I'm not very familiar with adwords and signup tracking but the implementation looks pretty straightforward.

In the base.html file, shouldn't we use is_secure in the call to show_tracker?

    {% block google-tracker %}
    {% if enable_google %}
        {% show_tracker %}
    {% endif %}
    {% endblock %}

-Chris

[Bruce Kroeze]

Good catch, thanks.  Updated in rev 637.

[Chris Moffitt]

One other thing.  I'm getting an error when running the unit tests.  The code here:

def google_track_signup(context):
    """
    Output a a new user signup in the format that Google Analytics needs.
    """
    request = context['request']
    contact = None

is giving a key error on 'request'

Are you seeing this?

[Bruce Kroeze]

Oh darn, I guess we need the request context processor, a thread local middleware, or we need to add request to the shop context middleware.  Probably the latter is the easiest.  I already include a request context processor, so I didn't catch it.

On 8/11/07, Chris Moffitt <ch...@moffitts.net> wrote: