search

neo09 / gwt-platform

Automatically exported from code.google.com/p/gwt-platform
0 stars 0 forks source link

Request for a feature to easily turn on sessions #99

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. According to the servlet spec, sessions must be explicitly turned on in 
code (a call to getSession(true) must be executed)
2. GAE follows the spec, so enabling sessions in the appengine-config.xml 
does not start a session, it merely enables them to be used
3. In a call to a servlet, some code must do this: request.getSession(true)

It would be nice if there were some code (ideally, say a single call or a 
couple of lines of configuration) that the framework provided that would 
accomplish this.

Sure, one *could* create their own Servlet, configure the servlet, and add 
the necessary call.  But, accomplishing doesn't really seem to fit into the 
platforms style (which, is to write ActionHandler<> implementations, and 
which don't have access to the request object).

For now, I've created a "dummy" Request / Action / Handler 
(InitiateSession) that extends UnsecuredActionImpl (so that it will always 
be dispatched).  And I've added the following code to 
DispatchServiceImpl.execute() [as the first code to run in that method]:

      if ( securityCookieName != null && ! this.sessionsEnabled ) {
          requestProvider.get().getSession(true);
          this.sessionsEnabled = true;
      }

For reference on sessions, see: 
http://stackoverflow.com/questions/595872/under-what-conditions-is-a-
jsessionid-created

Original issue reported on code.google.com by mike%she...@gtempaccount.com on 20 May 2010 at 3:03

GoogleCodeExporter commented 9 years ago 
Also, I created this class w/ 1 static method so it could be called easily from 
various places:

import InitiateSessionAction;
import InitiateSessionResult;
import com.google.gwt.core.client.GWT;
import com.philbeaudoin.gwtp.dispatch.client.DispatchAsync;

public class SessionInitiatior {
    public static void  initiateSessions(DispatchAsync dispatcher) {
        GWT.log("Ensuring sessions get turned on, calling 
InitiateSession...");
        dispatcher.execute( 
                new InitiateSessionAction(), 
                new ActionCallback<InitiateSessionResult>("Failed to 
initiate session...") {

                    @Override
                    public void onSuccess(InitiateSessionResult 
result) {
                        GWT.log("Sessions should now be 
initiated...");
                    }
                });
    }
}

Original comment by mike%she...@gtempaccount.com on 20 May 2010 at 4:11

GoogleCodeExporter commented 9 years ago 
Humm, you should use HttpSessionSecurityCookieFilter instead. This is the 
purpose of 
this filter.

More informations here :
http://code.google.com/p/gwt-platform/wiki/PortingV1

Original comment by goudreau...@gmail.com on 23 May 2010 at 3:25

GoogleCodeExporter commented 9 years ago 
Yes,

I've read those directions.  I think you're specifically referring to this:

Protecting against XSRF attacks
The code to do this is:
    bindConstant().annotatedWith( SecurityCookie.class ).to("MYCOOKIE");
You should also make sure your Action.isSecured methods return true for the 
actions you want to secure 
against XSRF attacks. One way to do this is to have your actions inherit from 
ActionImpl.

The cookie should contain a session-dependent random number that cannot be 
easily guessed by an attacker. 
You can set this cookie yourself as soon as the page is loaded, or you can use 
the "JSESSIONID" cookie, which 
can be easily enabled on a Tomcat server or on Google AppEngine.

If you don't want to use the "JSESSIONID" cookie, say because you don't want to 
enable it on AppEngine, then 
you can add eitherHttpSessionSecurityCookieFilter or 
RandomSessionSecurityCookieFilter to your list of filters. 
To do so, add the following line at the top of your configureServlets method:

    filter("*.jsp").through( HttpSessionSecurityCookieFilter.class );

However -- I *DO* want to use JSESSIONID.  At issue is -- how does one get the 
Session turned on at the 
server servlet?  They DO NOT get turned on auto-magically by simply enabling 
them in the appengine-
config.xml (they are only able to be used then).  

You and others in the forum seem unclear as to when JSESSIONID is created.  
From your own forums:

http://groups.google.com/group/gwt-platform/browse_thread/thread/69c3b439c2fd75e
3

And, if you read this post from the forums:

http://groups.google.com/group/gwt-platform/browse_thread/thread/0b189194945d92f
3

Christian created his own servlet to do exactly what I'm indicating needs to be 
done.  The only thing is, 
Christian is mistaken in thinking that AppEngine should do this atuomatically.  
AppEngine is complying with 
the servlet spec, and according to the spec:

JSESSIONID created IFF some servlet runs the following code: 

request.getSession(true)

see this discussion: 
http://stackoverflow.com/questions/595872/under-what-conditions-is-a-jsssessioni
d-
created

The HttpSessionSecurityCookieFilter -- its not doing the same thing, and its 
not what I (or Christian or some 
others) want to do/use.

The enhancement request is for a method inside the framework to accomplish what 
we've done through other 
means (generally outside the framework).

Original comment by mike%she...@gtempaccount.com on 24 May 2010 at 1:38

GoogleCodeExporter commented 9 years ago 
JSESSIONID created IFF some servlet runs the following code: 
request.getSession(true)

And yeah, my method wasn't perfect... and didn't work btw with a .html :D 
(Don't know why it worked once, and then no more).

Cookie securityCookie = new Cookie(securityCookieName, session.get().getId());

This line does exactly the same thing as request.getSession(true), because 
session get injected by Guice in HttpSessionSecurityCookieFilter's constructor, 
thus creating the 
session.

I agree that we should add a filter for AppEngine (that's why I starred your 
post) but in the meanwhile, using HttpSessionSecurityCookieFilter with 
JSESSIONID works fine.

But your method is even better... because we wouldn't need to use a filter 
anymore and thus, we could keep .html instead of .jsp ! I'll speak with Phil 
and I'll see if I add this 
in my next contribution later this week.

Sorry, I should have told you that in my first message :D

Christian

Original comment by goudreau...@gmail.com on 24 May 2010 at 6:07

GoogleCodeExporter commented 9 years ago 
Thanks Christian,

Yes, one definite benefit of my approach (and the reason I chose to implement 
it) -- 
it works with all file types, and doesn't require a filter.

If there were some filter that were easy to inject, *and* worked with all file 
types 
-- I'd be happy to use that.

Cheers
Mike

Original comment by mike%she...@gtempaccount.com on 25 May 2010 at 3:45

GoogleCodeExporter commented 9 years ago 
Mike, thanks for the stackoverflow link, it clarifies things for me. I like 
your idea 
of adding a session-initiating action  directly into GWTP to get rid of the 
requirement 
for filters.

As a side note, I believe filters can be made to work on HTML files too if 
these are 
made non-static in the appengine-web.xml. For details, see:
http://code.google.com/appengine/docs/java/config/appconfig.html#Static_Files_an
d_Resou
rce_Files

Original comment by philippe.beaudoin on 25 May 2010 at 4:37

GoogleCodeExporter commented 9 years ago

Original comment by philippe.beaudoin on 25 May 2010 at 4:37

GoogleCodeExporter commented 9 years ago

Original comment by philippe.beaudoin on 28 May 2010 at 8:25

GoogleCodeExporter commented 9 years ago 
Not entirely sure this falls in the scope of GWTP, so bumping it to 0.4 to give 
us time to discuss and think about it.

Original comment by philippe.beaudoin on 28 Jun 2010 at 6:08

GoogleCodeExporter commented 9 years ago 
After thinking about it, I don't think we should provide a specific action to 
turn on session, as these can be customized quite a bit. (For exemple, to use a 
"remember me" cookie.)

That being said, we should definitely discuss this option in the page about 
XSRF attack AND have a sample somewhere using an action to enable sessions.

Original comment by philippe.beaudoin on 16 Aug 2010 at 6:49

GoogleCodeExporter commented 9 years ago

Original comment by philippe.beaudoin on 16 Aug 2010 at 10:22

GoogleCodeExporter commented 9 years ago

Original comment by philippe.beaudoin on 22 Sep 2010 at 1:40

GoogleCodeExporter commented 9 years ago 
Hey Guys, maybe we're dumb but we lost a couple of days trying to work out what 
was going on here. Please add something to the wiki in lieu of a fix. 

Thanks to Westfork for his detailed bug / workaround

Original comment by benjamin...@gmail.com on 20 Dec 2011 at 11:42

GoogleCodeExporter commented 9 years ago 
..and Merry xmas to you guys, thanks for an awesome framework :)

Original comment by benjamin...@gmail.com on 20 Dec 2011 at 11:44