Thanks jhulford, Your points are taken in good faith. I think sometimes the problem is that I dont know what i dont know until someone points it out! Im learning all the time its been a very eye opening experience, and I cant wait until I can afford to employ some real programmers to do this all for me!
Thanks for all yr responses, very helpful. On 28 April 2010 16:04, jhulford <[email protected]> wrote: > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- 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.
