On 28 oct. 2010, at 13:00, Stefan Andersson wrote:
> Hej Jean Baptiste,
>
> >On the backend, RPC should not be linked to session.
>
> Backend = backend of client? ( I guess that is what you mean here ) The
> server handles the session id.
>
Backend = server side like in backend :-)
When I mean client, I write client or client side but we could stick to client
and server. I didn't thought backend could be misleading.
> Server:
> The http request call first hits the rpc servlet in the server. This servlet
> is always connected to a session id. I can not control that!
I know, that's one reason why we did our RpcJavaPOJO. The standard RpcJava
doesn't allow you to take control before RPC step, we improve that in our
contrib.
Not sure to understand what do you mean by servlet is "connected" to session id
... but we both know JEE servlet, so I assume it's ok.
>
> >Session should be managed on server side before reaching RPC.
>
> It is. As described above.
>
> There are a few interesting things with session id:
> 1. monitor a continous session from an identified ip
wow, I think linking IP and session is very dangerous. I won't do that.
> 2. authentication
OK, we're using session only for that.
I try hard to maintain our server as stateless as possible for a future load
balancing.
> 3. increased security
> a) session cookies -> easy to break
I didn't know that, could you explain ?
> b) jsessionid sent as a parameter -> securer and more difficult to tamper
Why would is be more secure ? I don't see how ...
>
> We use sessions in the above mentioned way...and one more:
> 4. identification for dynamically session dependent data requiring user
> response
Don't understand that point 4 ...
>
> Alt 4 is very important to identify the user response and to validate it.
>
> >RPC services are classes that should be singleton, no need to instanciate
> >more than once, and this instance should be reached by thread, like a
> >Servlet, inside or outside session, this should not be linked.
>
> Singleton yes, but they are always within a session.
"within" ???
Services can *access* session but are not store in session, what do you mean by
"within" ?
>
> >Once you managed HTTP/JEE session before reaching RPC, in a filter for
> >example or in your RPC servlet but before the RPC lib provided by the
> >RPCJava contrib, you can do what you want and JEE is very simple for that.
>
> It is the RpcServlet answering the http request call.
Yes but thanks to Java OO concepts we design our RPCJavaPOJO to be optionally
overridden where needed so you can take the control at various steps, including
before RPC call.
>
> >On the client side, you don't have to pass the jsessionid token or anything
> >else, this is all automatic from Java point of view.
>
> Yes, by cookies but it can be more easily tampered.
>
> >On each HTTP request, all cookies are passed (this is due to HTTP protocol)
> >and that's how jsessionid is transferred and how Java handle it for you on
> >server side.
>
> yes, it does.
>
> Well, every new rpc service call generates a new session id! This is the
> problem! This is the situation we would like to be:
It shouldn't and it is not the case in RPCJavaPOJO (I would consider it as a
bug).
>
> 1. new qx.io.remoteRpc() -> gives a connection and a session id kept all the
> time
Session are managed on server side, so I don't see how new qx.io.remoteRpc()
could instanciate a new JEE session.
> 2. rpcConnection.callServiceListeners(...) -> using the same session id as in
> 1) (this does NOT happen)
>
> Being able to include a sessionid (or other data) inside the RPC payload but
> not as part of the RPC method signature woulkd be great.
RpcJavaPOJO had been design to allow that. Parameters can be injected on server
side, before the call to the service but outside client side scope.
Let's take a real example now :
Here is a service, callable via RPC, on server, called a FooController :
import java.rmi.Remote;
import java.rmi.RemoteException;
public class FooController implements Remote {
public void deleteById(final ControllerContext cc, final long id) throws
RemoteException {}
}
To delete an instance of Foo by id, on client side, you would call the Rpc with
service = my.company.FooController
Method = deleteById
Params= [12]
Note : ControllerContect is not provided by client side.
This parameter is injected on server side to allow use of database,
transaction, ... (we are using OpenJPA from Apache)
Note2 : Remote is an empty standard interface, like the RemoteException.
In RpcJavaPOJO we rely only on already existing Java concept.
Of course, that injection is done in our servlet that inherit from the contrib
servlet.
By default, nothing is done, you have to do it in a subclass, but it is
possible.
Here is the method signature of the handleRPC in the JsonRpcServlet provided in
the contrib :
protected String doHandleRPC(final HttpServletRequest httpRequest, final String
requestString, final Object... extraParams) throws ServletException
Note the last parameter : extraParams, this is where you can pass as many extra
param as you want (Java 5 syntax) for the injection before RPC but on server
side so the client don't care about.
You could inject here what you store in the JEE session so no session or other
low level tech things is needed in the RPC Service that can stay "pure
business" like a clear crystal :-)
Here is the Foo class, the OpenJPA annotated persistent business object :
That way, persistence and serialization can be mixed but keep clear : transient
and Serializable for serialization.
@Transient only ; no persistence, so an attribute will not persist but still
going to the client side via Serialization.
@Transient and transient ; no persistence, no serialization, so an attribute
will not persist and also not going to the client side via Serialization.
@Basic (or other JPA annotation) and transient : persist in the DB but will not
go the client side
@Basic (or other JPA annotation) only (probably the default case) : persist in
the DB and will go the client side
=> This is flexible ! You take the control, not the contrib.
public class Foo implements Serializable {
/**
* Default technical primary key.
*/
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(nullable = false)
private Long id;
private transient String bar = "blabla";
}
I hope this clarify that parameter injection and the design of our contrib.
JBB.
> There-by allowing you to not have to include the
> session identifier as part of EVERY single RPC method signature and
> pushing security implementations into your serverside API.
>
>
> >That way, you can use session in the service without problem but I would
> >advice not to do so to maintain service independent from the underlying
> >techno.
>
> I agree to make things less dependent but security is more important.
>
> >I advice to pass extra param to the service : the needed value you find in
> >the session become function param that are pass to the service at the entry
> >point of the server side.
>
> yes, can you give an example of how you would do that?
>
> >That way, this extra param are not seen as param from the rpc client side
> >but the session do not pollute service that can stay functional/business
> >things.
>
> Can you explain what you mean here?
>
> We did look at the RPCJavaPOJO 6 months ago but we didn't think it was stable
> enough. We did notice that it was faster than RpcJava. We also noticed that
> it was easy to switch between them. Additionally, we missed the session id
> injection as in RpcJava.
>
>
> Stefan
>
> >By the way, we gave a contribution called RPCJavaPOJO, a very ugly name for
> >a good contribution ;-)
> This Java RPC is more open and configurable than RPCJava (and also quicker)
> but the software architecture assumption differs.
> We are working at attribute level and not using accessors for RPC which is
> good practice.
> This allow the code to rely on transient Java keyword that apply to attribute.
> This allow not to have accessor only for RPC but only because it is needed :
> putting accessor everywhere simply break encapsulation.
> Finally, you can have accessor or not : no impact on RPC.
> To avoid serialization, use transient, it is there for that purpose.
> Serializable classes must implement standard Serializable interface, this is
> the only constraint we have.
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev_______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
