Methods
app_user_check_cookie(req, session_token)
These method allow for implementations to manage cookies when dealing with browsers
Parameters:
| Name | Type | Description |
|---|---|---|
req |
object | |
session_token |
string |
- Source:
(async) cipher(clear_text, aes_key) → {string}
Override this method to use the application specific key format and run the cipher picked by the application.
The method is left abstract. It does not place any condition on the kind of cipher nor the format in which the cipher is passed.
Parameters:
| Name | Type | Description |
|---|---|---|
clear_text |
string | |
aes_key |
object | an AES key (or other) in a format that may be consumed by descendant library users |
- Source:
Returns:
- the clear (deciphered) text
- Type
- string
create_transition_record(t_type, sub_type) → {object}
The transition type is passed in as a parameter to the transition object constructor.
The subtype parameter is used to identify the class of the constructor. Take note that just a few types have their own classes. These are mostly for session management transitions.
The true transition subtype is for actual state machine or Petri net travel occuring in generalized transition engines.
All others are application specific with subtypes developed separately for each process.
Parameters:
| Name | Type | Description |
|---|---|---|
t_type |
string | |
sub_type |
string |
- Source:
Returns:
- the transition object
- Type
- object
extract_exposable_user_info(user, info)
Parameters:
| Name | Type | Description |
|---|---|---|
user |
object | a DB record representing a user |
info |
object | application specific information that may be used with the user data to extract information. |
- Source:
Returns:
- returns some user information -- default is the name
feasible(transition, post_body, req) → {boolean}
If a client request has access to a transition (state machine, Petri net), then one more kind of check will be employed. In this case, the transition is checked for feasibility; that is, the transition request may be limited in resoures it may use or it may not be supported computationally by the host machine.
Many types of applications may check feasibility in particular ways. For example, one application may check on rate limiting for certain transitions. Another, might check a balance. A fairly general check might be that a requested state transition targets an existing final state. One use already being used is to check if a signature can be verified with server side session data.
Parameters:
| Name | Type | Description |
|---|---|---|
transition |
string | |
post_body |
object | This is the request object sent by the client |
req |
object | This is request object derived from the HTTP header |
- Source:
Returns:
- true indicates feasibility
- Type
- boolean
finalize_transition(transition, post_body, elements, req) → {object}
Primary transitions that do not require seconday responses from the client and secondary transition processing may determine that a transition may be finalized. That is, a transition may be recorded as having completed allowing for the process to settle into a new state.
This method returns an object that indicates the state of the machine. The entirety of this object will be passed on to the client.
Parameters:
| Name | Type | Description |
|---|---|---|
transition |
string | |
post_body |
object | |
elements |
object | |
req |
object |
- Source:
Returns:
data destined to the client and with a report as to the state of the machine relative to the client
- Type
- object
(async) gen_wrapped_key(wrapper_public_key) → {string}
A method that returns a wrapped key after generating it. This method is left as abstract.
Parameters:
| Name | Type | Description |
|---|---|---|
wrapper_public_key |
object | a wrapper key |
- Source:
Returns:
- an empty string by default - the application sould override this method.
- Type
- string
(async) guard(asset, body, req) → {boolean}
This method intercepts requests that require processing, including dynamically generated assests and state transitions.
The guard method at a minimum will check to see if the CopiousTransitions innstance is checking for https and provide the check if it is.
There may be applications that provide a complex and calculated checks. But, in most cases, the checks wil be rapid and sufficient for the request to be accepted or rejected in a timely manner for the client.
Some applications may want to provide use of an ACL subprocess at this point.
Parameters:
| Name | Type | Description |
|---|---|---|
asset |
string | idenitifies the asset that is being accessed. |
body |
object | This is the request object sent by the client |
req |
object | This is request object derived from the HTTP header |
- Source:
Returns:
- true allows passage
- Type
- boolean
(async) guard_static(asset, body, req) → {boolean}
This guard, the static guard, is similar to the more general guard method. But, some implementations may be paired down
considerably knowing that the asset being accessed will be some static file. In particular, the file might have been preloaded.
Rate limiting might also be checked in the guard.
Usually, this method will access the static assets module to make queries about assets.
Parameters:
| Name | Type | Description |
|---|---|---|
asset |
string | |
body |
object | |
req |
object |
- Source:
Returns:
- true allows passage
- Type
- boolean
handle_cookies(result, res, transitionObj)
These method allow for implementations to manage cookies when dealing with browsers
Parameters:
| Name | Type | Description |
|---|---|---|
result |
object | |
res |
object | |
transitionObj |
object |
- Source:
key_for_user() → {string}
This is a key that may be set by the application. Generic code will not know the name of a field in a DB nor in objects received from the client. An application can override this method and let the generic methods operated with ti.
- Source:
Returns:
- a field name for accessing keys to user data
- Type
- string
match(post_body, transtion_object) → {boolean}
The match method is employed during a secondary transition phase of a transition or in secondary user processing (access management).
The default case is for the client to post a body with a field _t_match_field. This field is compared to a match field stored
in the elements sub-object of a chached transition object, one that has been created during the first phase of transition
processing.
Parameters:
| Name | Type | Description |
|---|---|---|
post_body |
object | |
transtion_object |
object |
- Source:
Returns:
- true for successful matching
- Type
- boolean
post_body_decode(udata) → {object}
Decodes fields from URI encoded to regular text
Parameters:
| Name | Type | Description |
|---|---|---|
udata |
object |
- Source:
Returns:
- the updated (decoded fields) of the user data object passed
- Type
- object
process_asset(asset_id, post_body) → {object}
This method generates a transition object for tracking the access to a guarded asset of some time. The transition object generated is not applied to a transition.
Parameters:
| Name | Type | Description |
|---|---|---|
asset_id |
string | |
post_body |
object |
- Source:
Returns:
- the transition object required to continue accessing the mime type asset
- Type
- object
process_transition(transition, post_body, req) → {object}
This method generates a transition object for a kind of transition. The transition object remains available for the duration fo the transition. There are two types of transition processes, one, those which work with one request from the client and two, those that work with more than one request from the client, one requiring secondary action.
When an application wishes to use a secondary action, it must set the secondary_action in the transition object.
Parameters:
| Name | Type | Description |
|---|---|---|
transition |
string | |
post_body |
object | |
req |
object |
- Source:
Returns:
- the transition object require to continue processing the transition step
- Type
- object
release_cookie(res, cookie_id)
These method allow for implementations to manage cookies when dealing with browsers
Parameters:
| Name | Type | Description |
|---|---|---|
res |
object | |
cookie_id |
string |
- Source:
session_accrue_errors(category, data, err)
Implementations of this method will keep track of errors accrued while processing a transition.
Parameters:
| Name | Type | Description |
|---|---|---|
category |
* | |
data |
* | |
err |
* |
- Source:
set_cookie(res, cookie_id, value, age)
These method allow for implementations to manage cookies when dealing with browsers
Parameters:
| Name | Type | Description |
|---|---|---|
res |
object | |
cookie_id |
string | |
value |
object | |
age |
Number |
- Source:
update_session_state(transition, post_body, req) → {boolean}
Often called by finalize_transition. This is an abstract placeholder for applications that choose to implement it.
It is provided allow clients to set session variables and to figure a status to return from finalize_transition.
This method suggests a set of parameter to such an update call. But, it does not indicate a way that it should be called by
finalize_transition.
Parameters:
| Name | Type | Description |
|---|---|---|
transition |
string | |
post_body |
object | |
req |
object |
- Source:
Returns:
- true for successful update of the session state
- Type
- boolean