Agreed, I guess I didn't make that clear in my initial mail.
-derek
Eneko Lacunza <[EMAIL PROTECTED]> writes:
> Hi,
>
> I think it should be optional to store the user/password for database
> access, for maximun privacy; like with the web navigator and login
> forms. If not stored (gconf or whatever), Gnucash should ask for it
> every time user opens the book.
>
> My 0.01 eurocent ;)
>
> P.D.: Keep on your excelent work!
>
> El lun, 24-05-2004 a las 17:10, Derek Atkins escribió:
>> [EMAIL PROTECTED] (Linas Vepstas) writes:
>>
>> > FYI,
>> >
>> > I just finished coding a proof-of-concept for saving & restoring
>> > arbitrary QOF objects to SQL tables & back. I've now started on
>> > a prototype that will 'do it correctly' i.e. mutate into the final
>> > version. You probbly don't want to look at the code, since its
>> > 'all wrong', but its in the dwi.sourceforge.net CVS tree, in
>> > the 'examples/basic-qof' directory. The prototype that was just
>> > started is in 'examples/qof-proto'.
>>
>> Cool!! I can't wait to see this proof-of-concept hit Gnucash. :)
>> Nice work!!!
>>
>> Question: What process are you using for cache coherency between the
>> QOF ram cache and the SQL backend? Are you depending on a SQL NOTIFY
>> events? Or are you performing a "refresh poll?" I'm hoping it's the
>> latter, because some SQL engines that I'd like to use don't support
>> notify events (e.g. SQLite).
>>
>> > Anyone have any brilliant ideas on how to manage user logins &
>> > permissions & etc?
>>
>> I would leave that up to the database... Provide a login dialog when
>> opening the book and "login" to the database (maybe make this
>> dependent of the actual database in use? E.g. SQLite probably doesn't
>> need it). Then just use the database's permission model to protect
>> the data.
>>
>> We might be able to get more clever and use per-table acls to control
>> which portions of the data a particular user has access to. But I
>> think this is going to depend greatly on what the underlying db can
>> do.
>>
>> Another thing that we should fix: username and password information
>> should NOT be in the book URL. This get's translated into a filename
>> and stored in ~/.gnucash/books/ which basically publishes your SQL
>> username and password. Not a good idea. Either we shouldn't cache
>> that information at all, or it should get stored in GConf or some
>> other "private" data source. Just my $0.02 (riddled with some
>> feedback from a few users on IRC).
>>
>> > --linas
>>
>> -derek
>
>
>
--
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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
