price-db storage via BackEnd?

[Derek Atkins]

I admit that the RPC backend is incomplete.  Indeed, there is NO
security in the RPC Backend at this time.  The code in the CVS
tree is mainly a proof-of-concept (slightly beyond experimental,
IMHO).  It is certainly not ready for prime-time, until:

	1) Security/Encryption is added to the TCP link
	2) User Authentication is added
	3) Price-DB is added
	4) We get this meta-data issue solved

Ideally I think i'd like to tie RPC specifically to Postgres, or
have some RPC-server configuration, instead of the current crock.
Luckily I only need to rev the RPC version number and that will
let us change the protocol and "cleanly" inform clients.

For user-login, it would be nice if the Backend were UI-agnostic..
For example, I'd like the process go be as follows:

UI	Book	RPC BE	RPC Svr	Book	PG BE
--	----	------	-------	----	-----
 open-book-------------------------------->
 <--------------------------------------- need login
 user/pass ------->
                  SSL ------>
                  <------- Ack
                  user/pass ------------->
 <--------------------------------------- ack


One approach is to require the UI to register an 'authentication'
callback with the Backend, so the Backend can call the callback
when it needs authentication.  This way the RPC Server can register
its own authentication callback and the Postgres Backend will
call the RPC Server rather than some GNC UI which doesn't exist.

Alternatively, error codes can be returned to signify various
'need-authentication' messages.  But I'm not convinced that works
quite as well as having an actual Backend callback into the engine.

This also doesn't even mention how to use Kerberos or SSL certificates
as an authentication scheme.

-derek

linas@linas.org (Linas Vepstas) writes:

> Even this is not hard.
> 
> This should be backend-specific.  The postgres backend can be /
> should normally be protected by a username-password login.  So that
> capability is there.  The rpc backend -- well, the backend interrface 
> for handling logins is in general is underspecified, and so I don't 
> know what rpc does.  On my to-do list for backend work is to clarify 
> login handling.  Anyway, what I'm saying is that for backends that 
> require a login, there is no difficulty in identifying the user.
> 
> (also: I could store per-user config info in the postgres backen as
> one big, opaque, long string.  No problem.  There is no reason that
> I see to educate postgres about the meaing of the contents of the 
> string.)  Again, the biggest issue is 'what's the user-login api 
> for the backend?'
> 
> -- 
> Linas Vepstas -- linas@gnumatic.com -- http://www.gnumatic.com/
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available