views:

172

answers:

2

What is the best practice when designing a mission critical signup form when it comes to using django-powered sessions?

  1. Is it generally considered ok to require the user to accept the session cookie?
  2. Are there any tips to maximize the percent of users who can accept the session cookie?
+8  A: 

We've used Django for this for almost 3 years and had zero problems. Of course you want to start with the form on an HTTPS page and not just submit to HTTPS -- it makes people feel safer.

Django doesn't play the "cookie in the URL" game like some PHP platforms, so if the user doesn't accept cookies it ain't gonna work.

Don't forget that once you have all of that sensitive data you have to handle it correctly. We only store the last 4 digits in the online database, and that's just for verification purposes. Everything else is managed through a back door connection to a separate company that handles subscription management for us.

Peter Rowell
It doesn't only "feel" safer, it _is_ safer! (Then I can check the signature of the website before I log in to my bank, not after I've sent my login + PIN...)
Marcus Lindblom
@Marcus: point taken. Believe it or not, I actually had to argue with a customer over this. I don't know if they thought that pages server with HTTPS cost extra, or what, but they initially resisted having the form page itself served with HTTPS.
Peter Rowell
Having the "cookie in the URL" is a dangerous feature. Let's say the user sends a link to someone else by simply copying the URL on the address bar, whoever clicks on that link will be logged in as the user. You don't want that.
Luiz C.
Peter Rowell
@Peter Rowell: How would a site protect itself against hijacked sessions when the only thing keeping track of the session is the URL? This implies there's another way to know who the user is.
Luiz C.
@Luiz C: In the situation we're talking about the URL contains *the session id*, not the entire session state. The id is used to look up the full session state in a DB (or whatever) *on the server*. If part of that state is the IP the user is coming from, then you can easily detect a hijack attempt. It's not perfect, but it does give the Black Hats another hurdle to jump.
Peter Rowell
+4  A: 

Don't try and deal with credit cards in your own app. There are all sorts of security issues. Hand off to one of the firms that specialise in that area - I've used RBS Worldpay successfully, but there are plenty of others, and they all expose good APIs.

Daniel Roseman
Thanks for your comment. Very good point about credit card processing. My concern is more about cookies than credit cards. I changed the wording of the question to more clearly reflect this and it no longer says "credit card".
Gattster
+1: All we do is collect the info and let netbilling.com handle all of the details. (BTW, netbilling is *not* cheap, but this site was classified by Visa as "adult oriented" even though it's target audience is older couples in committed relationships. Sigh.) I have another client site that used (past tense) PayPal for subscription management ... what a mess.
Peter Rowell