John, Generally there's a certain expected level of understanding when posting into a technical forum like this, which is why people will general preface a post with something like "I'm a beginner and I have some questions.." or something like that to indicate they're not at that level. I'd really suggest finding a book about building web applications in java - tutorials are mostly crap when trying to actually learn something new.
That said, here's some answers to your questions: 1) A web container is the server application where your server side code runs and accepts client HTTP requests...tomcat, jetty, websphere, etc. 2) You can configure the session timeout globally in your web application's configuration file, web.xml, also called the deployment descriptor. You can use the max interval method on individual sessions to make them deviate from the standard timeout value. 3) The way session tracking is done by default is by sending a session cookie (named session cookie because the cookie will expire after the user closes their browser) named 'jsession' id to the client browser as a session cookie. You can use this cookie to retrieve the session id on the client side if you need it for anything. 4) An application token is sometimes used to mitigate XSRF attacks. The server will associate a unique ID with the client and send it back to the client, the client then sends this token back with every request and the server validates the value matches what is expected for that session. 5) A request header contains all the meta information the browser sends to the server about the request - response header is server -> browser. There's a great firefox plug to view header information called Live HTTP Headers. Very useful. 6) Browser memory...essentially just a cookie for long term or medium length client session storage (ie. the duration a user has their browser open) - or can just mean objects stored in javascript global scope. HTML5 introduced a more robust storage mechanism, but it's not widely used or available on all browsers yet. 7) Originating Domain - See the domain property under the Set-Cookie response header section here: http://docstore.mik.ua/orelly/webprog/webnut/ch17_04.htm. Also note that any sort of client side code you run, you have to expect can be tampered with and modified. It's extremely easy to do this with javascript debugging tools like Firebug (another essential Firefox plugin when doing web dev.). Honestly, if keeping your traffic a secret is important then you can't really get by without SSL. If you can't use that with GAE, then you should think about moving to another server platform (Amazon EC2?) or dropping your custom domain and using SSL through the plain appspot URL (set up a forward from your custom URL to the appspot one). On Apr 28, 3:46 am, John Denley <[email protected]> wrote: > I understand what you are saying hazy1, you are right I dont know the > basics, but the reason for that is that I cant find anywhere where I can > properly LEARN the basics. > > If there is anywhere you can point me to that actually explains all this > stuff from the VERY BASICS then I would be very greatful. The reason Im > asking questions on this forum is to try to learn from friendly people who > might be able to help me understand these things specifically in the context > of GWT (and GAE). Its the back and forth question and answers format (like > this) that make this forum a useful place to discuss these concepts. > > The rest of this reply is not any kind of criticism of you personally, its > just an observation of the type of problem I keep finding myself having > whilst trying to figure all this stuff out (you touch on a very important > point so thank you for that). I started out building a proof of principle > and then grew it from there, I didnt ever really expect to suddenly become a > web developer. I would much prefer to employ "real" developers if only I > could afford them! > > The actual problem here is that I cant find any kind of tutorials that > explain all these concepts as if the person reading them has absolutely no > knowledge at all about how the basics work already. Generally speaking most > tutorials are written by experts who know all the terms and concepts like > they are second nature and often some terms are used like they are "normal > english" but they are not, they are technical terms where each one actually > needs further explaination on its own > > In your first point (1) there are a number of (probably very basic terms) > that I simply have no clue what they are, I will of course now go away and > google them and probably spend hours trying to figure out what they mean and > how they relate to the problems Im trying to overcome: > > - application token > - XSRF attacks (also known as CSRF - aprarantly simialr to a reverse XSS) > as defined > here<http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gw...> > - web container > - response header > - browser memory (fairly obvious, but where is it held and how can i > access it) > - originating domain (again seems obvious, but even the term "domain" is > not entirely specific, is this my appspot domain ( > www.ucanzoom.appspot.com) or the ACTUAL domainwww.ucanzoom.com) > especially as wikipedia <http://en.wikipedia.org/wiki/Domain_name>defines > "domain" as being a commonly used term for "domain name" and that "com" is > actally the top-level domain and that ucanzoom and appspot are subdomains > of > "com" so when people refer to subdomains they of course most often mean the > left most part (usually "www") of the full domain name but they could in my > example also be referring to the "www.ucanzoom" bit of " > www.ucanzoom.appspot.com") > - request header (presumably the opposite of the response header) > > I am sending the session ID to the client precisely to attempt to make > attacks more difficult, if it is in the response header and i can figure out > how to get it from there (given that im using GWT RPC calls) then thats > fine, and might work for me. > > In reply to your actual points however, its probably my incorrect use of the > basic language that is confusing you, but when talking about setting the > timeout on the session , what I mean is using the format > "this.getThreadLocalRequest().getSession().setMaxInactiveInterval(60*60)" > for example on the server to set the session to timeout after 1 hour of > inactivity. I apologise for mentioning "touching" the session prior to > actually testing it, as after sending that message i did go on to test this > process, turns out that the problem I had in understanding how this was > working was a bit of a schrodingers cat syndrome, where the act of getting > the client to ask for information about the cookie from the server was > changing its state by effectively "touching" it again, extending its "life". > It seems from what you have said is that this information is in the request > header anyway, but of course i didnt know this and all I wanted to do was > try to work out how sessions were working, as all the documentation seems to > be written by people who know what they are talking about for people who > already know what they are talking about. > > Hope this helps to explain the frustrations Ive been having in trying to get > to the bottom of this. I know from reading lots of other posts, both on here > and on stackflow that Im not the only newbie who is struggling to figure out > these concepts! > > Thanks for your response hazy1, its taken in the best of spirits and I hope > that this reply is also taken in the same way. > > J > > On 28 April 2010 04:49, hazy1 <[email protected]> wrote: > > > A lot of your problems are because you don't seem to have any idea how > > Java enterprise or web applications (of any kind) work with sessions - > > which is a totally separate issue from GWT. I suggest reading up on > > this prior to trying to use sophisticated frameworks like GWT/GAE. It > > is usually better to understand the basics of the underlying > > technology prior to using the most abstract ones. > > > 1) You do not need to send any session id (unless you have some > > application token - to mitigate XSRF attacks for example). The web > > container will send the session id in the response header. This > > session id is kept in the browser memory. The browser maps the cookie > > id to the originating domain. When making requests to the originating > > domain, the browser automatically will put the session id in the > > request headers. Look at the response/request headers yourself. > > 2) You do not 'set a timeout' on a session id or touch it or whatever > > else you think you do. This is typically a server/domain > > configuration parameter. Prior to worrying about regenerating session > > ids during the course of a session - learn the basics. > > > On Apr 27, 7:55 pm, John Denley <[email protected]> wrote: > > > OK, I think Im getting somewhere with all this, thanks so much for your > > > input Sri! > > > > Essentially all I need is an interim solution until GAE supports SSL. We > > are > > > actually not going to be storing data thats likely to be particularly > > > exciting for any hacker, the best they can hope for is a list of > > addresses > > > of people who use any one hairdresser in any one town! > > > > Regarding the "5 points" (Which I think we can now cut down to just one > > (the > > > use of sessions) going forward!) > > > > 1. I understand that any kind of encryption on the client is > > effectively > > > pointless without SSL, but its always going to be better than nothing! > > A bit > > > like saying that hding your front door key under a rock in your > > neighbours > > > front garden is no different to leaving it in your front door........ > > > 2. I figured TLS was something like SSL, either way its not on GAE > > yet, > > > so I cant use it yet! > > > 3. My passwords are being salted and hashed > > > (jBcrypt<http://www.mindrot.org/projects/jBCrypt/>) > > > before being stored. > > > 4. & 5. Still not sure i get how sessions really work. Ill keep > > reading > > > and trying to figure it out. But surely at some point I still need to > > send > > > the session ID from the server to the client right? As far as I can > > tell so > > > far, the session ID is generated on the server, so the right thing to > > do it > > > set a timeout on that sessionID and "touch" it every time the user > > makes a > > > call to the server, making sure that the sessionID has not timed out. > > There > > > are mentions in various places that you should "refresh/regenerate" > > the > > > sessionID on a regular basis during a logged in session, to keep it > > > fresh..... > > > > On 27 April 2010 10:16, Sripathi Krishnan <[email protected] > > >wrote: > > > > > If you can recommend a security framework that works with App Engine > > and > > > >> custom URL's without SSL/HTTPS and has really good documentsation for > > > >> complete dummies then please do let me know.... > > > > > As far as I know, the above is impossible. You cannot have security > > without > > > > ssl. You cannot have a custom domain *and* ssl *and* GAE (because it is > > > > prohibitively expensive for google). And you have already starred the > > GAE > > > > issue that speaks about it< > >http://code.google.com/p/googleappengine/issues/detail?id=792>, > > > > so there really isn't anything new for me to add. > > > > If you cannot use google's authentication, and if you can't use any of > > the > > > > (not-so-secure) workarounds described in that issue, I am afraid there > > is no > > > > way you can use GAE. I'd recommend discussing this in GAE discussion > > thread > > > > to get ideas from people. Either that, or just wait till GAE starts > > > > supporting SSL. > > > > > Additional responses to your comments > > > > > 1. It doesn't matter what encryption method you use on client side; > > it > > > > may be the most secure algo on earth. The problem is with the key > > > > management. JS code needs the key to encrypt. And if it is in the JS > > code, > > > > an attacker will always be able to get it. Ofuscation is just a very > > minor > > > > hurdle, its easy to read through it. > > > > 2. TLS is transport layer security< > >http://en.wikipedia.org/wiki/Transport_Layer_Security>, > > > > which is essentially the new SSL. > > > > 3. On the server side as well - you should NOT encrypt passwords. > > > > Encryption means there is a way to decrypt and recover the password. > > If you > > > > can decrypt it, an attacker will find a way as well. The recommended > > way to > > > > store passwords is to Salt and Hash them< > >http://www.aspheute.com/english/20040105.asp> > > > > . > > > > 4. Sessions can loosely be described as > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
