This example demonstrates how to create a 2-stage automation process.
The first stage collects initial data to be able to generate new set of requests that cannot be
performed using regular chaining functionality. Also, it demonstrates how to pass data to the
next stage.
Second stage uses data that was passed from the first stage in combination with parent requests
that was performed on the first stage.
The regular way exposes all fields to the template - this means anyone can alter the field contents before its being sent.
This allows the area to be used for possible phishing attacks.
Secure fields with automations
The best way to hide the fields is to move all functional fields away from the template (in this case into an automation)
These automation fields are never exposed to the public and cannot be intercepted.
The following example contains 3 templates:
check-page - the page where the user inputs the email (public page)
check-emailer-automation - the automation tha actually makes the email send
optional - just for an example we parse a template into the email content in the automation (not public)
check-page
In this example we only render the form when nothing is sent, we also never expose the automation trigger to the
template, thus a user cannot even alter its execution.
We use the input here to trigger the automation, and the only value that is being passed to the e-mailer.
<h1>Secure emailer</h1><p>Email from public/b2b without exposing the fields for editing</p><!-- Optional, we render the form only once and display a message once its already sent -->{{ if .Data.Parameters.inputEmailField }}
{{ .Tools.AutomationEvent "check-emailer-automation" (jsonSet `{}` "email" .Data.Parameters.inputEmailField) }}
<h2>Thanks!</h2>{{ else }}
<h2>Send me something</h2><formmethod="post"><labelfor="email">Add your email</label><inputtype="string"id="email"name="inputEmailField"><buttontype="submit">Send</button></form>{{ end }}
{{ .Data.Parameters.inputEmailField }}
check-emailer-automation
We read the email from the passed data and use it as the email, rest is hardcoded into the automation.
Here we also encode an optional template to the email body.
Create installation and navigate to created account
Create installation and navigate to created account
Method to be used where we would use a separate account to create a new erply account.
And then we would like the user to navigate to the created account without showing the default erply login.
Note that there are multiple workflows this can be used for:
Source account and created accounts are on the same erply domain.
Source account is on custom domain and the created account will use the erply domain.
Source account and created accounts are on the same erply domain
Since both run on the same domain then it’s enough to just run erply createInstallation.
The process there will automatically set the auth cookie for the created account to the browser and since
we are on the same domain then browser will automatically use it when we navigate to the created account.
<form type="post">
<input type="hidden" name="ErplyApi.Api.Post.createInstallation" value="createInstallation">
<!-- Required form fields would be here -->
<input type="text" name="ErplyApi.Api.PostParam.createInstallation.username"
value="15">
<input type="text" name="ErplyApi.Api.PostParam.createInstallation.password"
value="15">
<!-- Depending on what cluster the main account is the target url might need to be adjusted -->
<input type="hidden" name="Form.Redirect" value="https://template-engine-eu10.erply.com/[[ .Data.ErplyApi.Api.Requests.createInstallation.Response.Get `records.0.clientCode` ]]/en/store">
</form>
Source account is on custom domain and the created account will use erply domain
Note
Available from goerp version 1.314.0
In cases where the main app is on a different custom domain. In these case we cannot set cross domain cookies.
Instead, we can pass the session key in the query parameter, goerp will take care of the session creation itself.
<form type="post">
<input type="hidden" name="ErplyApi.Api.Post.createInstallation" value="createInstallation">
<!-- Required form fields would be here -->
<input type="text" name="ErplyApi.Api.PostParam.createInstallation.username"
value="15">
<input type="text" name="ErplyApi.Api.PostParam.createInstallation.password"
value="15">
<!-- Depending on what cluster the main account is the target url might need to be adjusted -->
<input type="hidden" name="Form.Redirect" value="https://template-engine-eu10.erply.com/[[ .Data.ErplyApi.Api.Requests.createInstallation.Response.Get `records.0.clientCode` ]]/en/store?authKey=[[ .Data.ErplyApi.Api.Requests.createInstallation.Response.Get `records.0.sessionKey` ]]">
</form>
Navigating to application routes
By default, accounts do not have any goerp applications installed. If we need to navigate to a new application then we would
need to set the application up to auto install.
Requirements:
The application needs to be published to the clusters store.
The application needs to be set as auto installed (request with a raji ticket).
Note
Also note that passing the key is only needed if we want to navigate the user to a bo user view. If the user is to be
navigated to a public page view then there is no need to pass the auth key.