OpenESignForms / openesignforms

Open eSignForms is the first open source SaaS web contracting platform
https://open.esignforms.com
107 stars 50 forks source link

Allow HTTPS POST to start a transaction automatically #50

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Have an external program do an HTTPS POST with name-value params to the 
transaction template's start URL.

What is the expected output? What do you see instead?
Today, it is assume that a user will follow-up and complete the first step.

What we'd like is for the post to be authenticated, and have the first party 
step automatically validate the data fields as if there was a user trying to 
complete the first step until the transaction's first step is completed. Then 
return a status code indicating the transaction started on success, or an error 
message if there's a failure.

This will allow a purely automated start of transaction without requiring a 
user be logged in and complete the first party step.

Original issue reported on code.google.com by yoz...@gmail.com on 25 Jan 2012 at 11:14

GoogleCodeExporter commented 9 years ago
First take:

We'll need to make a code change for the requirement that the HTTPS POST starts 
the transaction and auto-completes that first step, but we can surely make that 
work for our next release.  I am thinking that we'll have a few pre-defined 
params that will allow this to work: i.e. ESF_LoginUser and Esf_LoginPassword 
that will have to match an existing userEmail+password defined in the system, 
and to force it to complete the first step on submit, another param 
ESF_AutoCompleteFirstParty set to "true".  That way, we can handle a POST from 
the outside, authenticate that's a valid request, and auto-complete the first 
party so it goes to the second party right after.

Along with that step of ESF_AutoCompleteFirstParty=true, it will probably 
trigger a standard API response of:

OK:transaction-uid   (OK: meaning it was successful, "transaction-uid" being 
the unique transaction id that was started)
ERROR:message   (ERROR: meaning it was not started, with "message" being the 
error string describing the problem.

Normally, after the POST, the user would see the first document/package-page, 
but in an API, we don't want an HTML response, just a simple text response 
that's easy to parse for success/failure.

Original comment by yoz...@gmail.com on 25 Jan 2012 at 11:16

GoogleCodeExporter commented 9 years ago
Added in release 12.2.10.

Documented in the programming guide: 
http://code.google.com/p/openesignforms/wiki/ProgrammingGuide#Integration_Interf
ace_%28API%29

Original comment by yoz...@gmail.com on 13 Feb 2012 at 6:20