[cap-talk] fun with Capper and OFX financial transaction fetching

[Dan Connolly]

Capper is kinda fun to work with. I wish I had seen it sooner! I hope
to see more of this sort of stuff: investment in ocap style on the JS
platform.

The documentation works just fine for starting up (though the config
should probably default to localhost). To put together a non-trivial
app, I had to puzzle over the source of the examples. But it wasn't
too bad.

The main disappointment is that I don't get to use normal closure
style objects. I have to mutate this context.state thing. Oh well.

The good news is I get to use all the npm goodies such as banking (OFX).

I was able to put together Account objects that fetch 60 days of CC
transactions .

https://bitbucket.org/DanC/finquick/src/capper/take2js/README.md
9e09e00

Now I'd like to figure out an alternative to this step in my docs:

WARNING: This will store your credentials in clear-text in capper.db.

I'm noodling on how to use TOTP or some such to avoid storing
credentials in clear-text.

Then I'm thinking about deployment on sandstorm.

A wish: I'd love to see an authority-neutral module loader a la
makeSimpleAMDLoader.js.

https://github.com/tvcutsem/es-lab/blob/master/src/ses/makeSimpleAMDLoader.js

Then I could start to refactor stuff like http libraries (superagent)
and the banking OFX stuff to use it.

--
Dan Connolly
http://www.madmode.com/
_______________________________________________
cap-talk mailing list
cap-...@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk

[Dan Connolly]

On Sat, Jan 2, 2016 at 5:39 PM, Dan Connolly <dc...@madmode.com> wrote:
> https://bitbucket.org/DanC/finquick/src/capper/take2js/README.md

>
> Now I'd like to figure out an alternative to this step in my docs:
>
> WARNING: This will store your credentials in clear-text in capper.db.

I found a solution that works at my desktop:

70 ef458f26c63e 2016-01-03 21:56 -0600 http://www
use freedesktop secret store to avoid cleartext OFX passwords in capper.db

I'm still thinking about how and whether I want to deploy in sandstorm...

Meanwhile, I'm reasonably happy with the access graph now:

excerpt from README:


## Fetch 60 days of transactions

### Create an OFX institution object

For `discover` or `amex`:

$ discover=@`node --harmony server -make ofxies.makeInstitution
discover | tail -1`

The resulting `$discover` should be a webkey a la
`@https://localhost:1341/ocaps/#s=Yslejls...`.

### Put your OFX account credentials in the freedesktop secret store

The credit card number, username, and password are combined into one
secret, separated by spaces; `protocol` and `object` attributes are
used for lookup:

$ echo 601.... con... sekret | secret-tool store --label='My
Discover' protocol OFX object disc1

Then make a webkey for the freedesktop secret store:

$ store=@`node --harmony server -make ofxies.makeKeyStore | tail -1`

And make another for access to just the relevant entry:

$ key=@`node --harmony server -make ofxies.makePassKey $store
protocol OFX object 8146 | tail -1`


### Create an account object

Now we're ready to make a webkey for the account:

$ disc1=@`node --harmony server -make ofxies.makeAccount $discover
$key | tail -1`
finquick/take2js/Capper$ echo $disc1
@https://localhost:1341/ocaps/#s=abc123...

### Fetch

Access the webkey from above and hit **Fetch**; after a few seconds, a
table your transactions going back 60 days should appear.

[Marc Stiegler]

Glad you're enjoying Capper. The inability to use closures across shutdowns is a disappointment to me too. The silver lining is that it is really easy to make many different kinds of upgrades, adding and deleting instance variables, as the simple example. This is very different from using waterken, for which adding a new instance variable was, on a good day very painful, and under many important circumstances was actually impossible. And we won't even mention the delightful way that anonymous closures could get confused across maintenance on waterken, an impossible failure to debug.

Honestly, being able to do maintenance upgrades that involve modifying the data in the objects is so important over the long term that this is more than a silver lining; it is a benefit that may be comparable to being able to use closures. For DecideRight2, I have been repeatedly surprised that I've never had to throw my database away and start over, despite my warnings to alpha users that I might wipe it out at any time :-)

When Kenton did his first friam presentation on sandstorm, I pressed him really hard on how you would ship application-generated webkeys out to the users and have accesses directed back to the right app, since I wanted to run Capper under sandstorm. It was not possible at that time. I do not know if that has changed.

--marcs

[Kenton Varda]

On Tue, Jan 5, 2016 at 5:46 PM, Marc Stiegler <ma...@skyhunter.com> wrote:

When Kenton did his first friam presentation on sandstorm, I pressed him really hard on how you would ship application-generated webkeys out to the users and have accesses directed back to the right app, since I wanted to run Capper under sandstorm. It was not possible at that time. I do not know if that has changed.

Hmm, I don't remember this conversation, so I don't remember exactly what you're looking for, but Sandstorm offers a number of ways to implement webkeys. That said, ultimately Sandstorm apps are best-served by letting the platform implement the access control (which it may do using webkeys or other methods), so if what you're providing is infrastructure for capabilities then there may be some friction since Sandstorm is also trying to provide that.

Anyway, a Sandstorm app can export HTTP-based APIs (for consumption by machines, not humans) as documented here:

    https://docs.sandstorm.io/en/latest/developing/http-apis/

When you have a Sandstorm app open in your browser, you can click the key icon in the topbar to get an interface for generating a webkey to the app's HTTP API. This is displayed in the form "https://hostname/#token", but in fact the token part goes into the HTTP Authorization header as described in the docs. (We do this to prevent a human with a web browser from opening these resources directly, since we want humans to go through the Sandstorm UI for sandboxing and other purposes.)

If you want to host multiple logical objects within a single grain (fine-grained app instance), you can implement your own internal capabilities in the form of unguessable paths. We are working on making it possible for a grain to export multiple capabilities in a way that Sandstorm is aware of them (and can provide automatic auditability, revocability, etc.) but that's not quite ready yet. Usually, it makes more sense to create a whole new grain for each object.

-Kenton