This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Cade book (page 144) discusses the risks on usind Cookies and URL Rewriting for session tracking, and concludes risk is high on URL Rewriting which I could not understand completely. Can anyone explain this point further? Thanks in advance.
Storing the session ID in the URL requires a relatively short session ID. That may make it difficult to prevent hackers from breaking into other people's sessions by modifying the session ID. If you make the session ID a cookie or hidden form field, then first of all the hacker needs to be a bit smarter to hack his own browser first. Second, you can make the session ID larger, which makes it harder to guess a valid session ID.
The 'Professional Java Server Programming J2EE Edition' points to an interesting point about URL rewriting: "URL rewriting requires that all pages in the application be dynamically generated. URL rewriting cannot be enforced for static HTML pages, because the unique URL path parameter (the jsessionid) is dynamic and differs from user to user."
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com