Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Cookies at XML Europe 2004 -- Call for Particip ation
 >All the state must be in the client: > http://groups.yahoo.com/group/rest-discuss/message/3594 (Baker) > http://groups.yahoo.com/group/rest-discuss/message/3583 (Fielding) That's an oversimplification. The resources referred to by the URI can have state and this state is stored on the server. The server does not have to expose the complete resource state to the client. >The server cannot trust the client to not modify the session state, >and it may have privacy concerns about exposing the entire state to >the client in the first place. Therefore the server must encrypt >the entire session state (if it even has it all) and encrypt it. It >then gives this to the client so that the client can present it back >on future requests. In a properly designed system, it doesn't have to encrypt very much. For instance shopping cart contents would normally be stored as part of the resource state on the server. I'm not certain I know exactly what you mean by "entire state", but if you're including resource state in the "entire state", then the server does not need to give the entire state to the client, nor does it need to worry about client modification of that state. The only questions the server needs to ask itself are: 1. Do I know how to return a representation of the resource for which the client has presented me a URI? 2. Did the client also present the necessary authorization credentials for this resource? The server responds based on the answers to those two questions. (Actually that's GET. POST and PUT are a little more complicated but not greatly so.) > (Let's ignore if that's done via Cookies or via querystring >parameters in a URL.) In order to do this, we must use public-key >encryption. For security (and REST state:) reasons, we cannot use a >faster symmetric algorithm like 3DES or AES. We could use https to >protect the content, but then we're back to shared state (the SSL >context, but maybe REST doesn't care since that's just a transport >issue). You're right. REST doesn't care about the transport protocol. SSL is fine. >Therefore, the server has to do a public-key decryption on every >single incoming request in order to authenticate the client. That >is not scalable. It makes the server completely susceptible to >trivial DoS attacks, for example. What feels wrong about this to me is that there are scalable, secure sites in existence today that use SSL to encrypt sensitive transactions. It's not obvious to me why this is more expensive than those sites. It may be more expensive for sites that are not using SSL. However, I'm not convinced it's cost-prohibitive or subject to DOS attacks. Perhaps there's some point I'm missing here. Is it that SSL uses public key encryption only to exchange a symmetric key, and actually uses 3DES or some such symmetric algorithm for most data? But digest authentication does not require the encryption of everything, so it's cheaper than decrypting the entire page, and you can still use HTTP over SSL with basic authentication if you prefer. -- Elliotte Rusty Harold elharo@m... Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
