On Mo, 2009-12-07 at 23:10 -0500, Marc wrote: > While I agree with the cookie (as long as it has a short expiration), > another way to do this is by using expiring tokenization (credentials+ some > unique data for the transaction) in the URL header (see section 14.8 at > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html). Tokenization > substitutes some random string for confidential data (such as credentials).
This is essentially what I said about passing variables in the URL. The important thing still is information hiding, though: you don't want the user to have any clue what those variables mean so they can't modify them too easily. This is also why you should never expose critical variables (e.g. user ID) to possible modification. > The payment card industry uses this in the form of an authorization code for > card transactions. Add to the data represented by the token some unique > data (maybe a random number or some data from the last transaction - it > doesn't matter as the token does not expose the data in any way) for each > http transaction so you have unique token in each header and you can get an > essentially stateful session with a method of checking authentication that > has some spoof protection built in. The problem to keep in mind, though, is that your users may be multi-tabbing, i.e. keeping several pages open at the same time. Don't ever rely on a linear experience unless you're dealing with something inherently linear like a survey (though in that case you should probably try to keep it to one page, possibly updated with JavaScript requests if the form doesn't look too friendly on one page) or a check-out process. > Wrap it all in SSL/TLS and then you've > got something. Granted, this requires some serious server side work, and is > probably not a good beginner exercise, but if this level is what you > need.... I have never coded anything like this in Python, but I can see > abstractly how it could be done (I'm a novice with Python). If you're bored, > you can read http://www.shift4.com/pdf/TokenizationWhitePaper.pdf especially > sec1:7. I agree that if you're going for high security/safety tokenization can help, but for most intents and purposes it really isn't necessary. The idea is to avoid re-submission (especially of counter-intuitively side-effect non-free actions like GET requests) and make each action uniquely identifiable, if I understand the method correctly. This is normally only necessary for things like checkouts (keep track of the order ID and make sure the customer can't accidentally place an order twice e.g. by double-clicking the submit button or re-clicking it if the connection hangs) or form submission that affects the server state (e.g. posting a message to a forum, sending an e-mail, ...). SSL/TLS is also usually overkill for most purposes. Certificates provided by many non-commercial authorities will still trigger security warnings in most browsers, so the only way to get one that isn't counter-productive (i.e. diminishes trust rather than increasing it -- dodgy certificates are still valid certificates) is to shell out the big money -- and unless you're into serious business (i.e. anything big enough to justify the expenses), you probably can't be arsed. Cheers, Alan Plum _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor