Rob Heittman <rob.heittman <at> solertium.com> writes: >I genuinely don't fully understand the distinction of a "surrogate" or "fake" session versus a "real" one in this context. This is probably a failure of my education. Can you (or someone else who gets this) give me a reference to some reading material? ======== Here is an article on Wikipedia (it does not operate though with my frivolous terminology): http://en.wikipedia.org/wiki/Session_(computer_science)
>What is a good reference implementation of a sufficiently secure system that could be emulated or connected to in Restlet? Who does it "right?" I'm not being facetious, I'm asking so that I can study it and propose some ideas, write or adapt an external library that provides what you asked for. ========= I would not dare to give you such reference. It looks like that sooner or later in any JEE (and not only) implementation vulnerabilities are discovered. This is a very practical issue - I am struggling these days with such with Weblogic. That's why I simply assume that a home-grown implementation will not withstand a serious security scrutiny (of course it's nothing more than just practical assumption). The Wikipedia article gives some insights regarding "faked" session security issues. >I'm sorry if you got the impression that censorship or prohibition is going on. Still, you made your case in a public forum that Restlet should contain a session mechanism. I feel pretty strongly that it shouldn't, so I responded. I think that people should have easy access to any number of session (or "session surrogate") mechanisms that adapt as easily as HTTP servers and clients to Restlet, but I don't think that Restlet should contain or provide its own. This amounts to an "establishment of religion" that I feel strongly would be poisonous. To overextend the metaphor: I certainly don't advocate prohibition of alcohol. But I also don't advocate the government canonizing Jack Daniels as the national drink and issuing a bottle to every taxpayer of drinking age. Just let people choose something instead of being spoon-fed a solution. Is that an unreasonable position? ======= I would also love to have an "easy access to any number of session mechanisms ... that adapt to Restlet." The question is how these "mechanisms" are going to materialize in Restlet framework. I see three options here. One - they appear as a part of the original framework. Two - they appear as a part of the framework as a later addition by a third party (outside the core development team). Three - they will never appear in Restlet framework. Personally, I would prefer #1. Why not #2? Because with what I do and my customers I do not have luxury to risk. I would just say that based on my experience this risk is much higher with #2 than with #1 (which BTW also presents this risk). If #3 - well, I am afraid I will not be able to use (very, very regretfully) this framework in a number of projects. >From technical standpoint I am not a big fan of sessions myself. My advocacy comes from very practical considerations. Among them is my hope and desire that Restlet framework will thrive, and I am the first to let people choose. But what are the options? At this moment I do not see any. Perhaps my concerns are unfounded, and I simply do not enough knowledge/skills to see the point in this statement that I quoted in my article: "direct mapping of REST concepts to Java interfaces (Resource, Representation, Connector, Component, etc.); their resource-oriented design removes the need for in-memory sessions, a major scalability issue with Servlets." So, same way, if someone can help me with references that would explain the above quote (its part about removing the need), I would certainly appreciate it. Serge
