Pragmatic Paddy

I was trying to book a flight on jetblue.com yesterday, and I had a horrible experience. When you go to jetblue.com and search for a flight you are redirected to jetblueairways.com, initially I didn’t notice this. After I entered in my credit card information (with my Bank of America card) and hit submit, I was redirected to http://securesuite.com/bankofamerica , or a similar url. On this page I was asked for the last 6 digits of my social security number and my email address. I hesitated and looked up securesuite.com.

securesuite.com is apparently part of Visa’s “Verified by Visa” program. There were very few hits on google for the site, and most of them were people worried about phishing scams. I did a whois on securesuite.com and got these results.

   Registrant:
      cyota
      yaron shohat
      8200 Greensboro Drive Suite 1100
      Mclean, VA 22102

      Email: IAAG_DNS_Hostmaster@rsa.com

   Registrar Name....: REGISTER.COM, INC.
   Registrar Whois...: whois.register.com
   Registrar Homepage: www.register.com

   Domain Name: securesuite.net

      Created on..............: Fri, Aug 23, 2002
      Expires on..............: Sun, Aug 23, 2009
      Record last updated on..: Sun, Nov 09, 2008

   Administrative Contact:
      RSA, The Security Division of EMC
      IAAG DNS ADMIN
      8200 Greensboro Drive Suite 1100
      Mclean, Va 22102
      US
      Phone: +1.8665606153
      Email: IAAG_DNS_Admin@rsa.com

   Technical Contact:
      RSA, The Security Division of EMC
      IAAG DNS TECH
      8200 Greensboro Drive Suite 1100
      Mclean, Va 22102
      MS
      Phone: +1.8665606153
      Email: IAAG_DNS_Tech@rsa.com

   DNS Servers:

   pdns1.ultradns.net
   pdns5.ultradns.info
   pdns4.ultradns.org
   pdns6.ultradns.co.uk
   pdns2.ultradns.net
   pdns3.ultradns.org

Visit AboutUs.org for more information about securesuite.net

AboutUs: securesuite.net

Register your domain name at http://www.register.com

What the fuck. I don’t care if it is really sanctioned by Visa, and is a legitimate site, I won’t submit any information to such a poorly administered site. This is horrid, I don’t know who is responsible Visa, Bank of America, Jet Blue, a hacker who got into Jet Blue, or Jet Blue’s credit card processor, and frankly I don’t care.

At this point I went back to the previous page, and realized that I hadn’t been filing in my credit card information on jetblue.com, but jetblueairways.com. I opened a new browser and went to jetblue.com going through the same steps and I realized that searching for a flight on their home page redirects you to jetblueairways.com. Next I looked at the form on the last page from jetblueairways.com where I wrote in my credit card info, to see if it submitted to jetblueairways.com or securesuite.net,  apparently that page does submit to jetblueairways.com and the response gives an http redirect to securesuite.net.

I will call jetblue and my bank today to see what is going on.  Whatever the result, this was a horrible experience.  If this was legitimate, in some ways it is even more scary.  I had a hard time understanding what was happening, and I’m a programmer who deals with the web everyday, my parents are dead in the water.

I was setting up django on Scott’s machine for django development.  In addition to the normal quirks
manage.py runserver
doesn’t work normally. You get no updates in the shell when you load a page, unlike on unix systems, where you see access logs. When you a save a file in your django project, it forces the webserver to reload, at which point you see all the previous logs.

This behaviour is annoying enough for access logs, but it makes pdb unusable, which in turn makes development much less fun. After digging through the django/manage.py/basehttp/wsgi/pdb/cmd.py source I stumbled onto the problem.

Django uses

sys.stdout.write("foo")

to write access logs and other information from the server to the shell.  Calling sys.stdout.flush(), will cause your shell to update with the most recent server output. When you save a file, it causes django to terminate the current server and start a new one. killing the current server causes stdout to flush. Making the server call flush in all the right places would require editting django code, or monkey patching, thankfully getting pdb to work under windows is much easier. use this function

import pdb
def set_trace():
    p = pdb.Pdb()
    p.use_rawinput = False
    p.set_trace(sys._getframe().f_back)
set_trace()

if you look at the code in cmd.py, when raw_input is True, sys.stdout.flush() isn’t called, otherwise it is.

Good luck, I hope this is helpful