Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-08 Thread Thomas Broyer 


On Thursday, June 7, 2012 10:40:23 PM UTC+2, Ryan McFall wrote:

 Thanks, Thomas, I searched through the methods in 
 ServiceLayerDecorator for something like this, but somehow missed 
 these. 

 Using report() from with the ServiceLayerDecorator doesn't allow me to 
 re-fire the RequestFactory request, giving me the A request is 
 already in progress error.  If I call die() then the exception is 
 still printed out, but the onFailure method of the Receiver is in fact 
 called, and I can re-fire the request.


Be careful though: if you enqueued two invocations in your context, and the 
second one generated the die() exception (meaning the first one has been 
processed), when sending the request a second time, the first invocation 
will be processed a second time too, so it'd better be idempotent! 

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/bY-yvxElckMJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-07 Thread Ryan McFall 
I'm well on my way to getting this to work.  I can determine whether
the method to be invoked requires authentication, and whether or not
the user is currently authenticated.

Currently, what I've done is defined a new runtime exception and
thrown that exception in my ServiceLayerDecorator if an
unauthenticated user tries to invoke a method requiring
authentication.  I've then overridden doPost in my sub-class of
RequestFactoryServlet to catch this exception and set the status code
of the response to be 401.

Unfortunately, this doesn't quite work.  I get the following in my
server console when this exception is thrown by my code:

SEVERE: Unexpected error
edu.hope.cs.surveys.editor.server.SessionExpiredException: Session
expired
at
edu.hope.cs.surveys.editor.server.ActiveSessionDecorator.invoke(ActiveSessionDecorator.java:
17)
at
com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.invoke(ServiceLayerDecorator.java:
111)
at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.processInvocationMessages(SimpleRequestProcessor.java:
455)
at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:
225)
at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:
127)
at
com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:
133)
at
edu.hope.cs.surveys.editor.server.JandyRequestFactoryServlet.doPost(JandyRequestFactoryServlet.java:
28)

I see that SimpleRequestProcessor has a setExceptionHandler method
which is responsible for creating a ServerFailure object.  Do I need
to provide a custom exception handler to the RequestProcessor?  Or is
there some other way of catching the failure caused by the invoke
method of my ServiceLayerDecorator?

Thanks,
Ryan

On Jun 5, 11:13 am, Ashwin Desikan ashwin.desi...@gmail.com wrote:
 Thomas is correct. I had tried the route of creating two separate RF's. But 
 that involves more work in comparison to annotations. In fact I changed my 
 approach post Thomas suggestion in this forum quite sometime bac

 ~Ashwin

 Sent from my iPhone

 On Jun 5, 2012, at 7:38 PM, Thomas Broyer t.bro...@gmail.com wrote:





  On Tuesday, June 5, 2012 3:58:22 PM UTC+2, Ryan McFall wrote:
  After I wrote my original follow-up to Thomas' message, I thought of
  having different services - one for methods that require
  authentication, and one for those that don't.  Then I can map my
  ServletFilter to the URL for the service that requires authentication,
  and not map it to those that don't.

  That seems easier to me than the annotation route.  Anyone have any
  reasons to think otherwise?

  It won't work. RequestFactoryServlet loads from the classpath, so unless 
  you somehow constrain the classpath of each servlet to only contain the 
  classes you want to expose, the unauthenticated servlet would be able to 
  load the services requiring authentication, therefore allowing 
  unauthenticated access to them.
  In other words, that's not how RF has been designed.
  --
  You received this message because you are subscribed to the Google Groups 
  Google Web Toolkit group.
  To view this discussion on the web 
  visithttps://groups.google.com/d/msg/google-web-toolkit/-/fl0PLdvGKHUJ.
  To post to this group, send email to google-web-toolkit@googlegroups.com.
  To unsubscribe from this group, send email to 
  google-web-toolkit+unsubscr...@googlegroups.com.
  For more options, visit this group 
  athttp://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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-07 Thread Thomas Broyer 
If you go the ServiceLayerDecorator route, you can no longer use an HTTP 
status detected by a custom RequestTransport, you're pluggin *into* the RF 
protocol, not *around* it.
Try using the die() or report() methods from ServiceLayerDecorator and see 
how they behave.

On Thursday, June 7, 2012 8:30:35 PM UTC+2, Ryan McFall wrote:

 I'm well on my way to getting this to work.  I can determine whether 
 the method to be invoked requires authentication, and whether or not 
 the user is currently authenticated. 

 Currently, what I've done is defined a new runtime exception and 
 thrown that exception in my ServiceLayerDecorator if an 
 unauthenticated user tries to invoke a method requiring 
 authentication.  I've then overridden doPost in my sub-class of 
 RequestFactoryServlet to catch this exception and set the status code 
 of the response to be 401. 

 Unfortunately, this doesn't quite work.  I get the following in my 
 server console when this exception is thrown by my code: 

 SEVERE: Unexpected error 
 edu.hope.cs.surveys.editor.server.SessionExpiredException: Session 
 expired 
 at 
 edu.hope.cs.surveys.editor.server.ActiveSessionDecorator.invoke(ActiveSessionDecorator.java:
  

 17) 
 at 
 com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.invoke(ServiceLayerDecorator.java:
  

 111) 
 at 
 com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.processInvocationMessages(SimpleRequestProcessor.java:
  

 455) 
 at 
 com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:
  

 225) 
 at 
 com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:
  

 127) 
 at 
 com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:
  

 133) 
 at 
 edu.hope.cs.surveys.editor.server.JandyRequestFactoryServlet.doPost(JandyRequestFactoryServlet.java:
  

 28) 

 I see that SimpleRequestProcessor has a setExceptionHandler method 
 which is responsible for creating a ServerFailure object.  Do I need 
 to provide a custom exception handler to the RequestProcessor?  Or is 
 there some other way of catching the failure caused by the invoke 
 method of my ServiceLayerDecorator? 

 Thanks, 
 Ryan 

 On Jun 5, 11:13 am, Ashwin Desikan ashwin.desi...@gmail.com wrote: 
  Thomas is correct. I had tried the route of creating two separate RF's. 
 But that involves more work in comparison to annotations. In fact I changed 
 my approach post Thomas suggestion in this forum quite sometime bac 
  
  ~Ashwin 
  
  Sent from my iPhone 
  
  On Jun 5, 2012, at 7:38 PM, Thomas Broyer t.bro...@gmail.com wrote: 
  
  
  
  
  
   On Tuesday, June 5, 2012 3:58:22 PM UTC+2, Ryan McFall wrote: 
   After I wrote my original follow-up to Thomas' message, I thought of 
   having different services - one for methods that require 
   authentication, and one for those that don't.  Then I can map my 
   ServletFilter to the URL for the service that requires authentication, 
   and not map it to those that don't. 
  
   That seems easier to me than the annotation route.  Anyone have any 
   reasons to think otherwise? 
  
   It won't work. RequestFactoryServlet loads from the classpath, so 
 unless you somehow constrain the classpath of each servlet to only contain 
 the classes you want to expose, the unauthenticated servlet would be able 
 to load the services requiring authentication, therefore allowing 
 unauthenticated access to them. 
   In other words, that's not how RF has been designed. 
   -- 
   You received this message because you are subscribed to the Google 
 Groups Google Web Toolkit group. 
   To view this discussion on the web visithttps://
 groups.google.com/d/msg/google-web-toolkit/-/fl0PLdvGKHUJ. 
   To post to this group, send email to 
 google-web-toolkit@googlegroups.com. 
   To unsubscribe from this group, send email to 
 google-web-toolkit+unsubscr...@googlegroups.com. 
   For more options, visit this group athttp://
 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 view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/2m9y2JopvAYJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-07 Thread Ryan McFall 
Thanks, Thomas, I searched through the methods in
ServiceLayerDecorator for something like this, but somehow missed
these.

Using report() from with the ServiceLayerDecorator doesn't allow me to
re-fire the RequestFactory request, giving me the A request is
already in progress error.  If I call die() then the exception is
still printed out, but the onFailure method of the Receiver is in fact
called, and I can re-fire the request.

Ryan

On Jun 7, 3:06 pm, Thomas Broyer t.bro...@gmail.com wrote:
 If you go the ServiceLayerDecorator route, you can no longer use an HTTP
 status detected by a custom RequestTransport, you're pluggin *into* the RF
 protocol, not *around* it.
 Try using the die() or report() methods from ServiceLayerDecorator and see
 how they behave.



 On Thursday, June 7, 2012 8:30:35 PM UTC+2, Ryan McFall wrote:

  I'm well on my way to getting this to work.  I can determine whether
  the method to be invoked requires authentication, and whether or not
  the user is currently authenticated.

  Currently, what I've done is defined a new runtime exception and
  thrown that exception in my ServiceLayerDecorator if an
  unauthenticated user tries to invoke a method requiring
  authentication.  I've then overridden doPost in my sub-class of
  RequestFactoryServlet to catch this exception and set the status code
  of the response to be 401.

  Unfortunately, this doesn't quite work.  I get the following in my
  server console when this exception is thrown by my code:

  SEVERE: Unexpected error
  edu.hope.cs.surveys.editor.server.SessionExpiredException: Session
  expired
          at
  edu.hope.cs.surveys.editor.server.ActiveSessionDecorator.invoke(ActiveSessi­onDecorator.java:

  17)
          at
  com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.invoke(S­erviceLayerDecorator.java:

  111)
          at
  com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process­InvocationMessages(SimpleRequestProcessor.java:

  455)
          at
  com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process­(SimpleRequestProcessor.java:

  225)
          at
  com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process­(SimpleRequestProcessor.java:

  127)
          at
  com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(R­equestFactoryServlet.java:

  133)
          at
  edu.hope.cs.surveys.editor.server.JandyRequestFactoryServlet.doPost(JandyRe­questFactoryServlet.java:

  28)

  I see that SimpleRequestProcessor has a setExceptionHandler method
  which is responsible for creating a ServerFailure object.  Do I need
  to provide a custom exception handler to the RequestProcessor?  Or is
  there some other way of catching the failure caused by the invoke
  method of my ServiceLayerDecorator?

  Thanks,
  Ryan

  On Jun 5, 11:13 am, Ashwin Desikan ashwin.desi...@gmail.com wrote:
   Thomas is correct. I had tried the route of creating two separate RF's.
  But that involves more work in comparison to annotations. In fact I changed
  my approach post Thomas suggestion in this forum quite sometime bac

   ~Ashwin

   Sent from my iPhone

   On Jun 5, 2012, at 7:38 PM, Thomas Broyer t.bro...@gmail.com wrote:

On Tuesday, June 5, 2012 3:58:22 PM UTC+2, Ryan McFall wrote:
After I wrote my original follow-up to Thomas' message, I thought of
having different services - one for methods that require
authentication, and one for those that don't.  Then I can map my
ServletFilter to the URL for the service that requires authentication,
and not map it to those that don't.

That seems easier to me than the annotation route.  Anyone have any
reasons to think otherwise?

It won't work. RequestFactoryServlet loads from the classpath, so
  unless you somehow constrain the classpath of each servlet to only contain
  the classes you want to expose, the unauthenticated servlet would be able
  to load the services requiring authentication, therefore allowing
  unauthenticated access to them.
In other words, that's not how RF has been designed.
--
You received this message because you are subscribed to the Google
  Groups Google Web Toolkit group.
To view this discussion on the web visithttps://
  groups.google.com/d/msg/google-web-toolkit/-/fl0PLdvGKHUJ.
To post to this group, send email to
  google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
  google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group athttp://
  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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-05 Thread Thomas Broyer 


On Monday, June 4, 2012 10:17:52 PM UTC+2, Ryan McFall wrote:

 I am having issues when I want to resubmit some requests to the server 
 when the server-side logic indicates it should happen.  In particular, 
 here's what happens: 

 1.  The user logins in, which causes an object (SurveyResponseHeader) 
 to be created on the server-side, and sent back to the client.  edit 
 is then called on the client side on that object. 

 2.  The user fills in a set of SurveyResponse objects into a list 
 contained by the SurveyResponseHeader object (and a corresponding 
 request is made to save the object on the server). 

 3.  The user submits the survey responses, but the session has timed 
 out on the server.  An error code is sent back to the client, and the 
 user is asked to re-authenticate. 

 At this point, I want to resubmit the request that caused the error; 
 it should succeed on the server now because the session has been 
 restarted.  However, I can't use the same request object because I'll 
 get the request is already in progress error message. 

 Rather than tell you everything I've tried, I'd like to hear what 
 people think is the right way to accomplish this.  I can provide more 
 details if needed, but I want to keep the description simple at least 
 to start. 


You have to make sure you convey the session-expiry-error as a transport 
error or general failure, and not as a service method return value.
Using the DefaultRequestTransport, any non-200 response from the server 
will be a transport error, so handling session expiration from a servlet 
filter on the server and responding with a non-200 status code (let's say, 
for instance, a 401, or 400; make sure you don't redirect to your login 
page though!) should Just Work(tm).
To tell the difference between a real server failure and session expiration 
though, you'll have to make your own RequestTransport on the client 
(possibly extending DefaultRequestTransport) and define some kind of 
protocol (shared knowledge) with the server. Have a look at how it's done 
in the MobileWebApp sample in the GWT SDK: 
http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/mobilewebapp/src/main/java/com/google/gwt/sample/gaerequest/
 It's 
specific to Google AppEngine but is really easy to adapt to whatever you 
use. The trick is to make sure you don't set a security-constraint on the 
RequestFactoryServlet in your web.xml, and instead handle the absence of 
authenticated user from code (in a servlet filter is the easiest)

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/4IdupKo3KhAJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-05 Thread Ryan McFall 
Thanks for the ideas, Thomas.

Two questions on the response:
1.  I was hoping to detect this within my service method, rather than
at a higher level like a servlet filter.  Is it possible to return a
non-200 error code from within the service method?  I tried getting
the thread local HttpResponse object and changing its status code, but
this had no effect.

2.  If I do write a servlet filter, there are only certain service
methods that I want this code to apply to (for example, I use a
service method, rather than the built in servlet authentication to
authenticate the user, and I certainly don't want to require a valid
session during this call).  From what I see in the sample code you
posted, it looks like that application is doing this on every
request.  What is the best way to differentiate which service
method(s) are being called as part of the request?  Are there classes
available that will help me parse the request payload on the server
and identify the methods being called?

Ryan

On Jun 5, 5:21 am, Thomas Broyer t.bro...@gmail.com wrote:
 On Monday, June 4, 2012 10:17:52 PM UTC+2, Ryan McFall wrote:

  I am having issues when I want to resubmit some requests to the server
  when the server-side logic indicates it should happen.  In particular,
  here's what happens:

  1.  The user logins in, which causes an object (SurveyResponseHeader)
  to be created on the server-side, and sent back to the client.  edit
  is then called on the client side on that object.

  2.  The user fills in a set of SurveyResponse objects into a list
  contained by the SurveyResponseHeader object (and a corresponding
  request is made to save the object on the server).

  3.  The user submits the survey responses, but the session has timed
  out on the server.  An error code is sent back to the client, and the
  user is asked to re-authenticate.

  At this point, I want to resubmit the request that caused the error;
  it should succeed on the server now because the session has been
  restarted.  However, I can't use the same request object because I'll
  get the request is already in progress error message.

  Rather than tell you everything I've tried, I'd like to hear what
  people think is the right way to accomplish this.  I can provide more
  details if needed, but I want to keep the description simple at least
  to start.

 You have to make sure you convey the session-expiry-error as a transport
 error or general failure, and not as a service method return value.
 Using the DefaultRequestTransport, any non-200 response from the server
 will be a transport error, so handling session expiration from a servlet
 filter on the server and responding with a non-200 status code (let's say,
 for instance, a 401, or 400; make sure you don't redirect to your login
 page though!) should Just Work(tm).
 To tell the difference between a real server failure and session expiration
 though, you'll have to make your own RequestTransport on the client
 (possibly extending DefaultRequestTransport) and define some kind of
 protocol (shared knowledge) with the server. Have a look at how it's done
 in the MobileWebApp sample in the GWT 
 SDK:http://code.google.com/p/google-web-toolkit/source/browse/trunk/sampl...It's
 specific to Google AppEngine but is really easy to adapt to whatever you
 use. The trick is to make sure you don't set a security-constraint on the
 RequestFactoryServlet in your web.xml, and instead handle the absence of
 authenticated user from code (in a servlet filter is the easiest)

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-05 Thread ashwin.desi...@gmail.com 
Ryan,

You can create your own custom annotation (for example : LoggedIn). Apply
this on all methods you want to authenticate the user/ session to be
validated.

Define your own ApplicationRequestFactoryServlet and
ApplicationServiceLayerDecorators. Override the invoke method under
ServiceLayerDecorator and validate for the presence of @LoggedIn
annotation. If present, check if the user session is valid.

regards
Ashwin



On Tue, Jun 5, 2012 at 4:08 PM, Ryan McFall mcfall.r...@gmail.com wrote:

 Thanks for the ideas, Thomas.

 Two questions on the response:
 1.  I was hoping to detect this within my service method, rather than
 at a higher level like a servlet filter.  Is it possible to return a
 non-200 error code from within the service method?  I tried getting
 the thread local HttpResponse object and changing its status code, but
 this had no effect.





 2.  If I do write a servlet filter, there are only certain service
 methods that I want this code to apply to (for example, I use a
 service method, rather than the built in servlet authentication to
 authenticate the user, and I certainly don't want to require a valid
 session during this call).  From what I see in the sample code you
 posted, it looks like that application is doing this on every
 request.  What is the best way to differentiate which service
 method(s) are being called as part of the request?  Are there classes
 available that will help me parse the request payload on the server
 and identify the methods being called?

 Ryan







 On Jun 5, 5:21 am, Thomas Broyer t.bro...@gmail.com wrote:
  On Monday, June 4, 2012 10:17:52 PM UTC+2, Ryan McFall wrote:
 
   I am having issues when I want to resubmit some requests to the server
   when the server-side logic indicates it should happen.  In particular,
   here's what happens:
 
   1.  The user logins in, which causes an object (SurveyResponseHeader)
   to be created on the server-side, and sent back to the client.  edit
   is then called on the client side on that object.
 
   2.  The user fills in a set of SurveyResponse objects into a list
   contained by the SurveyResponseHeader object (and a corresponding
   request is made to save the object on the server).
 
   3.  The user submits the survey responses, but the session has timed
   out on the server.  An error code is sent back to the client, and the
   user is asked to re-authenticate.
 
   At this point, I want to resubmit the request that caused the error;
   it should succeed on the server now because the session has been
   restarted.  However, I can't use the same request object because I'll
   get the request is already in progress error message.
 
   Rather than tell you everything I've tried, I'd like to hear what
   people think is the right way to accomplish this.  I can provide more
   details if needed, but I want to keep the description simple at least
   to start.
 
  You have to make sure you convey the session-expiry-error as a transport
  error or general failure, and not as a service method return value.
  Using the DefaultRequestTransport, any non-200 response from the server
  will be a transport error, so handling session expiration from a
 servlet
  filter on the server and responding with a non-200 status code (let's
 say,
  for instance, a 401, or 400; make sure you don't redirect to your login
  page though!) should Just Work(tm).
  To tell the difference between a real server failure and session
 expiration
  though, you'll have to make your own RequestTransport on the client
  (possibly extending DefaultRequestTransport) and define some kind of
  protocol (shared knowledge) with the server. Have a look at how it's
 done
  in the MobileWebApp sample in the GWT SDK:
 http://code.google.com/p/google-web-toolkit/source/browse/trunk/sampl...It's
  specific to Google AppEngine but is really easy to adapt to whatever you
  use. The trick is to make sure you don't set a security-constraint on
 the
  RequestFactoryServlet in your web.xml, and instead handle the absence of
  authenticated user from code (in a servlet filter is the easiest)

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-05 Thread Jens 


 You can create your own custom annotation (for example : LoggedIn). Apply 
 this on all methods you want to authenticate the user/ session to be 
 validated. 


Better do it the opposite way if you only have few methods that are allowed 
for unauthenticated users (I think thats more typically), e.g. create a 
@AllowUnauthenticated annotation and if its absent assume the user must be 
logged in. That way you have few opt-out methods instead of many opt-in 
methods.

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/Y7SWwBLfRlkJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-05 Thread Ryan McFall 
After I wrote my original follow-up to Thomas' message, I thought of
having different services - one for methods that require
authentication, and one for those that don't.  Then I can map my
ServletFilter to the URL for the service that requires authentication,
and not map it to those that don't.

That seems easier to me than the annotation route.  Anyone have any
reasons to think otherwise?

Ryan

On Jun 5, 8:22 am, Jens jens.nehlme...@gmail.com wrote:
  You can create your own custom annotation (for example : LoggedIn). Apply
  this on all methods you want to authenticate the user/ session to be
  validated.

 Better do it the opposite way if you only have few methods that are allowed
 for unauthenticated users (I think thats more typically), e.g. create a
 @AllowUnauthenticated annotation and if its absent assume the user must be
 logged in. That way you have few opt-out methods instead of many opt-in
 methods.

 -- J.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-05 Thread Thomas Broyer 


On Tuesday, June 5, 2012 3:58:22 PM UTC+2, Ryan McFall wrote:

 After I wrote my original follow-up to Thomas' message, I thought of 
 having different services - one for methods that require 
 authentication, and one for those that don't.  Then I can map my 
 ServletFilter to the URL for the service that requires authentication, 
 and not map it to those that don't. 

 That seems easier to me than the annotation route.  Anyone have any 
 reasons to think otherwise?


It won't work. RequestFactoryServlet loads from the classpath, so unless 
you somehow constrain the classpath of each servlet to only contain the 
classes you want to expose, the unauthenticated servlet would be able to 
load the services requiring authentication, therefore allowing 
unauthenticated access to them.
In other words, that's not how RF has been designed. 

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/fl0PLdvGKHUJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Resubmitting RequestFactory request when server side logic requires it

2012-06-05 Thread Ashwin Desikan 
Thomas is correct. I had tried the route of creating two separate RF's. But 
that involves more work in comparison to annotations. In fact I changed my 
approach post Thomas suggestion in this forum quite sometime bac 

~Ashwin

Sent from my iPhone

On Jun 5, 2012, at 7:38 PM, Thomas Broyer t.bro...@gmail.com wrote:

 
 
 On Tuesday, June 5, 2012 3:58:22 PM UTC+2, Ryan McFall wrote:
 After I wrote my original follow-up to Thomas' message, I thought of 
 having different services - one for methods that require 
 authentication, and one for those that don't.  Then I can map my 
 ServletFilter to the URL for the service that requires authentication, 
 and not map it to those that don't. 
 
 That seems easier to me than the annotation route.  Anyone have any 
 reasons to think otherwise?
 
 It won't work. RequestFactoryServlet loads from the classpath, so unless you 
 somehow constrain the classpath of each servlet to only contain the classes 
 you want to expose, the unauthenticated servlet would be able to load the 
 services requiring authentication, therefore allowing unauthenticated 
 access to them.
 In other words, that's not how RF has been designed. 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Google Web Toolkit group.
 To view this discussion on the web visit 
 https://groups.google.com/d/msg/google-web-toolkit/-/fl0PLdvGKHUJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to 
 google-web-toolkit+unsubscr...@googlegroups.com.
 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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Resubmitting RequestFactory request when server side logic requires it

2012-06-04 Thread Ryan McFall 
I am having issues when I want to resubmit some requests to the server
when the server-side logic indicates it should happen.  In particular,
here's what happens:

1.  The user logins in, which causes an object (SurveyResponseHeader)
to be created on the server-side, and sent back to the client.  edit
is then called on the client side on that object.

2.  The user fills in a set of SurveyResponse objects into a list
contained by the SurveyResponseHeader object (and a corresponding
request is made to save the object on the server).

3.  The user submits the survey responses, but the session has timed
out on the server.  An error code is sent back to the client, and the
user is asked to re-authenticate.

At this point, I want to resubmit the request that caused the error;
it should succeed on the server now because the session has been
restarted.  However, I can't use the same request object because I'll
get the request is already in progress error message.

Rather than tell you everything I've tried, I'd like to hear what
people think is the right way to accomplish this.  I can provide more
details if needed, but I want to keep the description simple at least
to start.

Thanks,
Ryan

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.