endurox-connect

We could add session handling via caches (hits + expiry or new strategy of expiry update on access).

And use service access filter lists, something like:

[PERMISSIONS/USRMGMG]
read=Read user data
write=Add new user
update=Update user
delete=Delete user
list=List users

[RULES/USRMGMG]
# Accept any from sysadmin
accept 0 = ACL_SYSADMIN
# Reject if not having user name (thus no session)
reject 1 = !ACL_USERNAME
# verify that user belongs to insitution
reject 1 = !chk_inst_username()
accept 2 = ACL_READ && API_FNCODE=='read'
accept 3 = ACL_WRITE && API_FNCODE=='write'
accept 4 = ACL_UPDATE && API_FNCODE=='update'
accept 5 = ACL_DELETE && API_FNCODE=='delete'
accept 6 = ACL_LIST && API_FNCODE=='list'
# if we got so far, then accept
reject 99 = 1==1

[PERMISSIONS/LOGINSV]
read=Login into system

[RULES/LOGINSV]
# accept if have user name & password
accept 0 = API_USERNAME && API_PASSWORD
# reject if got so far...
reject 99 = 1

So we need API for:

restincl target service, loginsvc -> @GETSESSION, if missing, forward to @LOGIN (which forwards to @GETSESSION again for storing by session key...) -> @ACCESSRULES -> target_service

restincl target service, loginsvc -> @GETSESSION, if missing, forward to @LOGIN (which forwards to @GETSESSION again for storing by session key...) -> @GETACL -> @ACCESSRULES -> target_service

[@LOGIN]
LOGINSVC = <User login service>

[@GETACL]
ACLSVC = <User ACL Service>

Only needs to think how to limit the services which user can list in roles screen. Maybe we need some kind of system role and then filter service which to return to user and shall not return?

The project could fallback to following parts:

1. Generic access permissions checking service, for example "experms" to which "SRVCNM" is passed (target service). if experms config says forward, then if rules passed message is forwarded to SRVCNM, if no forward is set, then tpreturn tpsuccess is returned. Rules section can be configured too i.e. to use "[@RULES/SVCNM]" or "[@RULES2/SVCNM]", etc... Also default logic shall be defined, if no section found, then reject or accept the call. If call is not accepted, then EX_IF_ECODE shall be set to 8 -> and set corresponding message in EX_IF_EMSG e.g. "reject 99".

The server for each section shall add entry in new hash list which would hold the list of compiled rules linked lists. On new request, we lookup the hash, if entry is found, then go over the linked lists of permissions and evaluate the buffer. If hash entry is not found, then lookup the config section, if found, compile each rule, add to linked list, add linked list to hash which is build by section/subsection name.

2. Update restincl to have two 4x new params for each service (or default):

- "in"
- "inoptsvcs" comma separated list of vital service to be executed on buffer

"in_fltr_mand":"SVC1,SVC2,SVC3" 
"in_fltr_opt":"SVC3,SVC4,SVC5" 

"out_fltr_mand":"out1,out2,out3" 
"out_fltr_opt":"out4,out5,out6" 

"out_fltr_error":"errsv1,errsv2" 

for example:

/view/httpe/fail={"svc":"VIEWFAIL", "conv":"json2view", "errors":"http", "async":false, 
        "view_notnull":true, "in_fltr_mand":"VIEW2UBF", "in_fltr_opt":"AUDITREQ,AUDIT2", "out_fltr_mand":"UBF2VIEW", "out_fltr_opt":"AUDITRSP"}

Thus in this case the request will be chained via firstly via "in_fltr_mand" then via "in_fltr_opt" services.
The buffer format can be switched during the processing i.e. we might get json, and or view and "VIEW2UBF" will convert to UBF.

Also we might need a new buffer format, like "ubfemb", so that the raw message is embedded in the "EX_NETDATA", also for this
"ubfemb" we could load all header in the buffer, before forwarding filter chains. In case if chaining is enabled, then "SRVCNM" shall be set for in/out chains and afterwards deleted. for UBFEMB json2ubf buffers

At the response phase the "out_fltr_mand" could prepare in ubf buffer "EX_NETDATA" for sending response to network.

In case "in_fltr_mand" fails, then error shall be sent to network, if response code is 11 and buffer has EX_IF_EMSG/ECODE then this shall be loaded
in the response message. if fields are not available, then generic error code shall be provided to network.

• Error handling: **

- In case if any mandatory filter fail (in or out), the "out_fltr_error" is called and all list is OK on exec, then send EX_NETDATA + headers to network (assume error is loaded).
- if EX_NETRCODE is present, then return this HTTP code, else if "out_fltr_error" was ok, then return 200

- In case of out_fltr_error fails, return code 500, no headers and no data shall be responded.

- in case if EX_NETDATA is missing, return code 500 or EX_NETRCODE as said before.

The error mode is "ext" (like external). And buffer conversation mode is "ext" too. The mode will be strict.

With these changes we solve following issues:

- Can have a message convert servers
- Can chain a service access permission checkers

on response

- we can conver message back to network format via response converter

The filters:
"out_fltr_mand":"out1,out2,out3"
"out_fltr_opt":"out4,out5,out6"

"in_fltr_mand":"SVC1,SVC2,SVC3"
"in_fltr_opt":"SVC3,SVC4,SVC5"

"in_fltr_error":"errsv1,errsv2

Shall be used for restout too.

conv mode "ext".

In case of performing outgoing call, use out_fltr_X filters, when processing response use in_fltr_X. In case of error, use in_fltr_error.
In case of out filter fail, we return error code from last mandatory filter error. Or in case if there is not data buffer to send to network, the generic TPFAIL will be returned.

In case of incoming filter fail we call the in_fltr_error and return to call the service error code provided from it. If there is no in_fltr_error, then TPFAIL shall be provided to caller.

other option would be to use "fltr_err" for restin out services. in any case if have UBF buffer the filter response codes or target XATMI service response codes shall be loaded into UBF. New field with CVT_PHASE shall be provided which would be net, service, filter_in, filter_out constants. So that error engine would understand where failure have occurred.