Tuesday, September 20, 2011
Cookies are not (only) for eating
HTTP provides a mechanism for authentication that ask the browser either to send the username and the password more or less in clear text to the server (Basic authentication) or in a hash (Digest authentication). Believe it or not, but Digest authentication was and is a problem for some browsers, so practically only Basic authentication can be used in all environments. Common denominators tend to be small. Plus it is difficult to ask the browser to forget the username and password that has been entered after a certain time; it will be pretty much there as long as the browser is running.
Because of this, web servers started to use another technology, called “cookies”. There you can control how long a session will be valid and you can also control the layout that the user will see when logging in. This is today pretty much standard. And so we thought this is how you should log into the m9.
The m9 keeps all information related to a login session in a special object inside the built-in web server; not only the login credentials, but also session variables. For example, the identity that the user has chosen is stored in this session variable. Another one is the duration, after which the session will expire.
The snom m9 stores the cookies temporarily. Many users are concerned with permanent cookies (including me), and browsers today make a big distinction between permanent and temporary cookies. So there should be no problem. If you use the HTTPS transport layer, then the cookies will be exchanged between the browser and the snom m9 in an encrypted fashion, so that outside parties will not be able to see them in clear text. Because the web server does not care where the request comes from, it would be possible, if you know the session cookie, to resume the session from another computer; in other words, you could skip the login part and start editing user data just like that or use the powerful debugging possibilities as admin to do other bad things.