Month: February 2015

Pitfall – using redirection in your DNS settings

Hi Guys,

DNS settings have to be edited carefully only with complete knowledge. I’ve recently committed a blunder by adding redirection in CNAME record. Here goes the story-

We were using Gmail Work.  All our MX records were pointing to aspmx.l.google.com, alt1.aspmx.l.google.com, … respectively. For the sake of better google analytics, we had to redirect traffic from ‘example.com’ to ‘www.example.com’. I have added CNAME record in DNS settings. I’ve realized later, this change was not at all necessary as it will just help in serving request from naked domain. So, I have configured the redirection in server. I have a bad habit of not doing things when they are not necessary. As a result I totally forgot about that change in CNAME records.

We were able to send mails properly as usual but after a week I was with one of our client and he tried to send a mail to our email address. Bang .. it bounced back with 300kph. I was shocked.

After digging for some time, it finally caught me that I have redirected mails traffic too from ‘example.com’ to ‘www.example.com’. According to the MX records only naked domain traffic will be served by google servers. Finally removed that CNAME record. We had to wait till the DNS settings are updated completely and apologized to all our users because of my blunder.

Moral of the story – DNS settings are dangerous. Change them only when your are confident. Make a note of your TTL setting too before changing anything.

Thanks for your time !  Good Day !!

Advertisements

Changing SESSION_COOKIE_NAME setting in production – Django (For projects using SessionMiddleware)

Hi Guys,

While working on a project, we have pushed the code to production by setting SESSION_COOKIE_NAME=None without proper knowledge. We realized the problem when we enabled ‘www’ subdomain as a common practice. Session login was not happening as single signon for ‘example.com’ and ‘www.example.com’. If a user logins using example.com domain and if he visits http://www.example.com, he will be treated as not signed in. This happens as the cookie will be set to example.com by default and not for all sub-domains(www.example.com), viceversa.

Solution was to use ‘SESSION_COOKIE_NAME = .example.com‘ in your settings.py file. Caution: It will not allow the previous users to signin as there will be two session ids in their cookies when they try to login. The previous cookie has to expire for the user to login.

Work Around:
Extend default sessions middleware slightly like this-

from django.utils.importlib import import_module
from django.contrib.sessions import middleware
from django.conf import settings

class MySessionMiddleware(middleware.SessionMiddleware):
    def process_request(self, request):
        engine = import_module(settings.SESSION_ENGINE)
        session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME, None)
        if session_key is None:
            # Look for old cookie in request for auth purposes.
            session_key = request.COOKIES.get('sessionid', None)
        request.session = engine.SessionStore(session_key)

In your settings file, under MIDDLEWARE_CLASSES setting, change 'django.contrib.sessions.middleware.SessionMiddleware' to 'customsessionmiddleware.MySessionMiddleware'

Here I’m assuming your customsessionmiddleware.py file is present in project root folder where your manage.py file is present. If you have placed your file in some other folder just prepend it accordingly. Eg: if the file is at custom/middleware/customsessionmiddleware.py starting from your project root folder, then use ‘custom.middleware.customsessionmiddleware.MySessionMiddleware’.

Restart you app. Bang! now everything works as expected.

If you have not change cookie expiration time, after normal cookie expiration time (14 days) you can change the sessionsmiddleware to back the way it was.

Sources:
http://stackoverflow.com/questions/15625569/how-to-clear-cookies-for-old-session-cookie-path-in-django
http://www.finalconcept.com.au/article/view/django-creating-a-custom-middleware-component