Swing Client Security
Because of an small [discussion about the two different idempiere clients] (swing and zk) I had some thoughts about the security of the Swing client.
The swing client keeps a (simply obscured password) in his configuration file. With this password you can access the whole database. This is a security issue. What can we do about this?!?
I think the complex of Swing <-> Zk and his issues is an often discussed issue. I did this page to keep my knowledge and to let the next discussion begin on the shoulders of the last. :-)
See also Comparison of Clients.
- solutions on database level
- using the grant access rights security - but this is only per table: not very secure for our purpose
- using [partitioned tables] in postgres - with this we could divide tables by client and/or by organization
- using a kind of [Row Level Security] would be better. [It seems] that this will be implemented in PostgreSQL 9.3. I do not really understand why [rules], [Views] and [Triggers] may not do it. And I have no clue what that means for performance (It will be nothing comared to the Java persistence Layer but I don't know what happens to bulk operations and direct SQL queries in the code).
- solutions in the Swing Client
- We could connect an application server and get a one-time password (like a ticket). The server maintains a group of postgres Users on-the-fly (database security is the same as now but there is no openly accessable password file - we have to defend the persistence code in the Client, perhaps with a signed OSGi plugin or such).
- solutions with a new Client
- What is better with swing? (It is much faster than Zk in reaction on clicks.)
- If Zk would cache more data it would react much faster (CarlosRuiz mentioned that a GWT Client would work in such a way)
- We have to move the border of separation between server and client.
- Nobody has (yet?) the time, resources and will to build a complete new client architecture
- One way: another technology just where needed (for data entry, POS, etc.)
- Perhaps we could integrate a Java applet into the Zk.
- IMHO this applet can not be the whole now used Swing Client. Such a thing will not integrate well. It has to be a three-tier-client with it's own local data cache.
- What about installing Zk local on the same machine as the browser (to speed it up). Can we use many servers on one database?
chat between tbayen and CarlosRuiz at 2013-01-09