Resend payload after successful login

[GoogleCodeExporter]

It would be nice to have gwtsecurity be able to resend the original rpc payload 
after successful login.

This way no data would be lost after a session timeout.

Is this possible?

Original issue reported on code.google.com by steven.j...@gmail.com on 4 May 2011 at 8:53

[GoogleCodeExporter]

Yes, It's possible. These days I am working on this subject. 
and will reversion soon.

Original comment by kent.yeh...@gmail.com on 10 May 2011 at 6:30

[GoogleCodeExporter]

I have already worked out a solution to this based on some advice from serveral 
groups.  Basically I have created a callback called AuthCallback that 
implements the Command interface.  I modified the login window do contain a 
command queue.  The queue collects all of the failed rpc calls and then 
executes the commands that failed.

It's not as elegant as I would like but it suits my purposes.  I have attached 
some files for reference.  They are tied to the GXT project because I am 
playing with it for now.

Original comment by steven.j...@gmail.com on 10 May 2011 at 2:50

Attachments:

• RPCExample.txt
• Callback.java
• LoginWindow.java

[GoogleCodeExporter]

Steven:
  I had changed version to 1.0.3 for log in resend issue.
Usage please reference to 
http://gwtsecurity.googlecode.com/svn/trunk/javadoc/1.0.3/com/gwt/ss/client/logi
nable/LoginableAsync.html and examples.
If you have any idea. please discuss with me.

Original comment by kent.yeh...@gmail.com on 10 May 2011 at 5:46

[GoogleCodeExporter]

I spent a few minutes looking at the code for the LoginableGenerator and I am a 
little concerned that this method of code generation will be difficult to debug.

I am also trying to see how the LoginableService handles multiple asynchronous 
rpc calls to restricted resources.

Here is an example:

request 1 gets a list of users, request 2 gets a list of groups and both 
require authentication and authorization.  If request 1 displays the login box 
and request 2 doesn't.  When credentials are supplied do both requests then 
succeed or just request 1.

Does your code handle this situation?

Original comment by steven.j...@gmail.com on 10 May 2011 at 7:11

[GoogleCodeExporter]

You can find generator generate  a yourServiceAsync_Proxy.java file under 
project folder/target/.generated/you/package/path/ after maven execute goal 
"package". 

If you need to debug, copy yourServiceAsync_Proxy.java into you source path.
and remove LoginableAsync extension from yourServiceAsync.java.

Attachment is gssdemo1's GreetingServiceAsync proxy file.

Let me assume user net yet has authorization and
1. request1 & request2 need ROLE_USER
    when issue request1 and login process start.
    if user cancel login, then callback receive a LoginCancelException to stop running next.
    if user login as ROLE_USER, then proxy issue request1 again, and request2 has ROLE_USER authority to execute.
2.request1 need ROLE_USER and request2 need ROLE_ADMIN
   when issue request1 and login process start.
   if user login as ROLE_USER, proxy issue request1 again,
   and next requet2 owing of laking ROLE_ADMIN authority, callback will receive a GwtAccessDeniedException.

finaly, I saw AuthCallback.java, and I don't think to popup a default login box 
is necessary,
Maybe user don't like Remeber-Me option, maybe user has alternative login 
method...
I think it should determine by programmer themselves, and just to notify the  
login process result is enough.

Original comment by kent.yeh...@gmail.com on 11 May 2011 at 1:13

Attachments:

• GreetingServiceAsync_Proxy.java

[GoogleCodeExporter]

I am not sure I understand.  Are you saying for #1 that request 2 will be 
suspended while request 1 is waiting for the user to authenticate?  It may take 
the user several minutes to authenticate, and there may be several requests 
during the time it takes for a user to authenticate, especially after a session 
timeout.

I agree that AuthCallback.java would need to be more flexible for an api.  I 
was just trying to accomplish my task in the easiest method and I wanted to 
illustrate what I had done.

Overall I like the proxy idea much better.  I just want to make sure we don't 
functionality while a user is authenticating.

Original comment by steven.j...@gmail.com on 11 May 2011 at 1:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

OK, I admit that I misunderstand you need.

If you function is like 

public void doDescreteRequest(){
   remoteService.request1(....,new AsyncCallback(.....
   );
   remoteService.request2(...,new AsyncCallback(...
  );
}

It will be a problem.

When request1 start login process, whether request2 be blocked depends on how 
HasHandlers.startLogin.

If startLogin not blocked, then request2 execute immediately, then startLogin 
will execute twice.

I have a question, let me suppose that user has enough authority to run the 2 
requests.

How about request1 happen error? If request1 error occur, should request2 go 
next?

I think it will be more reasonable to re factor program like this

public void doTowRequest(){
  remoteService.request1(...,new AsyncCallback<ResultType>(){
      public void onSuccess(ResultType result) {
          remoteService.request2(..., new AsynCallback...);      
      }
      public void onFailure(Throwable caught) {
          //stop running
      }
  }
} 

Original comment by kent.yeh...@gmail.com on 11 May 2011 at 4:01

[GoogleCodeExporter]

I think I make a mistake.

public void doDescreteRequest(){
   remoteService.request1(....,new AsyncCallback(.....
   );
   remoteService.request2(...,new AsyncCallback(...
  );
}

Requst1 and request2 never block because they are asynchronous.

so startLogin must be called twice.

It will be a problem.

Original comment by kent.yeh...@gmail.com on 11 May 2011 at 4:53

[GoogleCodeExporter]

Shouldn't we create a ScheuledCommand queue that contains all of the proxied 
commands since the login handler was first called.  Once we get a successful 
login we would process each command.

Something like:

in LoginableGenerator:

startLogin(caught, new Scheduler.ScheduledCommand() { ...execute rpc request 
code here ... });

for startLogin:

queue.add(scheduledCommand);
if (!isHandlingLogin()){
  handleLogin();
}

We would need a service that listens for onLogin event and processes the queued 
scheduled commands.

Let me know what you think.  I think I may try and work it out tonight if I 
have time.

Original comment by steven.j...@gmail.com on 11 May 2011 at 3:22

[GoogleCodeExporter]

I think to solve discrete  request problem, designer should following 2 points.

1. Loginbox that implements HasLoginHandler should be a singleton bean.
2. Loginbox bean should be invoke startLogin() multiple.

Because Request1Async_Proxy and Request2Async_Proxy register LoginHandler to 
Loginbox that implements HasLoginHandler,
If login succeed then request1 and request2 will issue again, otherwise 
request1 and request2 will need to handle LoginCacelException within 
onFailure().

Original comment by kent.yeh...@gmail.com on 12 May 2011 at 2:45

[GoogleCodeExporter]

Perfect!  Very elegant solution.  I have created a patch for the 
LoginableGenerator that fixes the case where the rpc call doesn't have 
parameters.

One problem though....When I try and pass a set, list, or map with a generic 
type the compiler fails.  Here is the example:   

Set<Role> getRoles() throws GwtSecurityException;  // Fails
Set getRoles() throws GwtSecurityException;  // Works

The problem is the method created looks like this for both cases:

public void getRoles(final AsyncCallback<java.util.Set> callback)

When is should be:

public void getRoles(final 
AsyncCallback<java.util.Set<com.mjnservices.lms.jpa.Role>> callback)

I tried to fix it but I am new to generators and am having difficulty getting 
my debugger to step through LoginableGenerator.

Any ideas?

Original comment by steven.j...@gmail.com on 12 May 2011 at 5:33

Attachments:

• generator.patch

[GoogleCodeExporter]

OK.  Got it working.  Please see attached patch.  Includes previous patch.

Original comment by steven.j...@gmail.com on 12 May 2011 at 7:41

Attachments:

• generator.patch

[GoogleCodeExporter]

I found another problem with generateMethod when AsyncCallback had a void 
paramater type.  Please see attached patch.

Original comment by steven.j...@gmail.com on 13 May 2011 at 8:20

Attachments:

• returntype.patch

[GoogleCodeExporter]

It looks like I made a mistake or the patch didn't get applied correctly.  I 
have created another to fix the problem.

Original comment by steven.j...@gmail.com on 18 May 2011 at 1:13

Attachments:

• returntype2.patch

[GoogleCodeExporter]

Original comment by steven.j...@gmail.com on 9 Jun 2011 at 3:46

• Changed state: Fixed