Chrome Extension: Config + HTML META tag presence triggers simple 2-call RESTful web API

(All of this documentation is from our Trac, where is it correctly formated. Coder will have access to the Trac.)

1. provide navigation to plugin configuration

2. visibly indicate a Dynaceipt enabled page

1. "explicate pages" (pages with Dynaceipt data in them, as integrated by the sitee

The dock icon should remain enabled and functional at all times, even when not on a Dynaceipt enabled page.

On each page load the plugin will determine if the page should be processed. This should be as lightweight as possible and not interfere with non-Dynaceipt enabled pages.

### VVersion 0: Alpha[][1] {#Version0:Alpha}

* Purpose:

* Provide a basic but usable functional browser plugin for Dynaceipt explicitly enabled pages, namely displaying a receipt

* Allow for editing who/what

* * AAA:

* Session only saved

* Client side salted password hashing

* Architecture

* * Relatively static "container" plugin (will change infrequently)

* Remotely stored core logic JS module (will change as application evolves), stored on [url removed, login to view]

* Images stored on [url removed, login to view]

## Deliverables

## High Level Description[][2] {#HighLevelDescription}

The goal of the Dynaceipt Browser Plugin is to provide a browser based "automated receipt capture" client for the Dynaceipt platform. The plugin will contain a dock icon to

1. provide navigation to plugin configuration

2. visibly indicate a Dynaceipt enabled page

1. explicate pages (pages with Dynaceipt data in them, as integrated by the site)

The dock icon should remain enabled and functional at all times, even when not on a Dynaceipt enabled page.

On each page load the plugin will determine if the page should be processed. This should be as lightweight as possible and not interfere with non-Dynaceipt enabled pages.

## Browser Plug-In Specifications[][3] {#BrowserPlug-InSpecifications}

### Version 0: Alpha[][1] {#Version0:Alpha}

* Purpose:

* Provide a basic but usable functional browser plugin for Dynaceipt explicitly enabled pages, namely displaying a receipt

* Validate working relationship with plugin coder

* Publication: internal use only, demo to 3rd parties

* Provides basis for future specification and extensions of plugin

* Features

* Allow for editing who/what

* AAA:

* Session only saved

* Client side salted password hashing

* Screens

* [BasicUseCase0][4]

* Architecture

* Relatively static "container" plugin (will change infrequently)

* Remotely stored core logic JS module (will change as application evolves), stored on [url removed, login to view]

* Images stored on [url removed, login to view]

AAA Specifics

### Ver {#Version1:Beta}

## [][5] {#AAASpecifics}

The clear text password is never saved nor sent to the server. Instead it is salted and hashed (SHA-256). The salt (for development) is 'happyhappyjoyjoy'. The SHA-256 library selection is open to the developer. There is a [ wide selection to choose from][6], but the [ [url removed, login to view]][7] library looks good--Dynaceipt has tested the results, which are correct. Another tested option is [ jsSha2][8].

## Static Content Storage[][9] {#StaticContentStorage}

Static content will be stored on Dynaceipt's CDN. Locations:

* Images

* Chrome: Icon: Orange: [ [url removed, login to view]][10]

* Chrome: Icon: Blue: [ [url removed, login to view]][11]

* Chrome: Icon: Grey: [ [url removed, login to view]][12]

* Plug-in Logic:

* [ [url removed, login to view]][13] (TBD?)

* others?

## API[][14] {#API}

While the API and server is still under active development, it is solidifying. There may be small API changes during the plugin version 0 development. Browser<-->Server is via a RESTful API passing JSON objects. There is a simple two step "transaction begin" and "transaction commit" method call request/respons pairs. The below diagram describeds the various actions and documents involved in processing a receipt.

* Actions

* a1: a Dynaceipt enabled receipt is presented to the user

* a2: user initiates Dynaceipt receipt capture, document is sent to server

* a3: servers process Dynaceipt payload, return receipt information and who/what configuration

* a4: user modifies who/what + note and commits receipt

* a5: server stores and processes receipt

* Documents

* d1: transaction start request

* d2: transaction start response

* d3: transaction commit request

* d4: transaction commit response

[![[url removed, login to view]][15]][16]

## API Documents and examples[][17] {#APIDocumentsandexamples}

### trans start/stop: For processing a Dynaceipt enable page (v0)[][18] {#transstartstop:ForprocessingaDynaceiptenablepagev0}

* [v0d2][19]: Browser Plugin --> API Server (transaction start request)

* [v0d3][20]: API Server --> Browser Plugin (transaction start response)

* [v0d4][21]: Browser Plugin --> API Server (transaction commit request)

* [v0d5][22]: API Server --> Browser Plugin (transaction commit response)

[TransStartCommitExample][23]: example API usage with cURL and json documents in flat files.

### trans simple: manual entry (v3+)[][24] {#transsimple:manualentryv3}

* [v0d9?][25]: Browser Plugin --> Server API (transaction simple request)

* [v0d5][22]: Server API --> Browser Plugin (transaction simple response, identical to transaction commit response)

## UML for Objects passed over API[][26] {#UMLforObjectspassedoverAPI}

[![[url removed, login to view]][27]][28]

Ingenieurwesen JavaScript Projektmanagement Softwarearchitektur Testen von Software Windows Desktop

Projekt-ID: #2665328

Über das Projekt