Re: [Openledger-developer] Impl. of "general ledger transaction"

[Klavs K. <kl...@vs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

on 02-03-2005 23:16 Tony Fraser wrote:
[SNIP]

| Umm... Am I missing somthing? post_transaction() only does 1
| SELECT.

and subselects for employeeid - but no. don't mind little confused me :)

|> I must be missing something.
|
|
| Maybe you missed the start of the all_transactions() function.
| There's lots of selects in there.

The all_transactions, retrieves all transactions on a given account I
guess?
IMHO we'd ONLY have 1 function for that:
getTransactions ($parameters) - but the paramter be an object here -
or just plain info like startdate,enddate, etc. with NULL(ie. empty
parameters) in the ones you don't want to search on?
[SNIP]

|> I'd be very happy if you could tell me what I'm missing? It does
|> ofcourse save the employee ID of the user who posted it.
|>
|> What should we do with that - just let it be parameter to the
|> postTransaction function? Or should we build a login scheme of
|> some sort for the API (seems a bit hmm.. to me)?
|
|
| For now I think you could ignore it but the API seems like the
| right place for security to me. There's no sense reinventing the
| wheel every time you integrate a new application or create a new
| GUI.

Hmm. The only "partly" secure way to do it - would be to make a login
function, which takes user/pass as paramters and returns a hash of
that(+salt saved by API itself) - after verifying it. then ALL
functions would have to have a $hash paramter, to verify the caller
was verified.

Only problem, is that when you're dealing with local processes - You'd
need to ensure other programs can't peak at the running scripts (ie.
the caller) memory segment, as they'd be able to get the $hash and get
access.

Just like they could sneak into SL gui, if they sniffed the cookie
ofcourse :)
p.s. this could be reused - as it is the same way login's work - so
the GUI would just save that $hash in the client cookie. Unless I'm
just tired and there's a better way?

What do you think?

- --
Regards,
Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8  B8DA 3D3A 0B79 7E06 3C62

"Those who do not understand Unix are condemned to reinvent it, poorly."
~  --Henry Spencer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCJreXPToLeX4GPGIRAnMLAJ0WF41XspU32O7fxX7SpYX9Oyp2vwCdE1YV
gA4F+JpddT79rLBCyiYBJ3Y=
=RWRb
-----END PGP SIGNATURE-----