Access Journey Apps
Last updated
Last updated
Gabriele
MyApps allows you to develop and publish your own Apps and contents into the WiFi onboarding flow. In particular, you can use the Access Journey orchestrator in the Cloud4Wi Dashboard, to publish your custom App as you can already do with the out-of-the-box apps available in your Cloud4Wi subscription.
MyApps offers a set of utilities that allows to easily manipulate the experience of the user and to retrieve context information (such as user, location and organization data) to create an highly relevant, personalized and localized experience.
The Access Journey tool, available in the Cloud4Wi Dashboard, allows you to publish your App in different steps of the onboarding experience, before or after the main Splash Page home, forcing the user to go through a series of pages before getting online:
Connect
this step is the first one in the journey and shows a page before the Splash Page. In this step, the user is still anonymous, so MyApps offers only location information (where the user is connecting from).
This is a video that shows a journey that prompts a video advertising page as soon as the user connect, using the Connect step of the access Journey.
Login attempt
This step happens every time a user logs in. This step is triggered before the actual network access authorization, so the user is not online yet.In order to be authorized, the user still needs to proceed with the next steps of the journey.
This behavior has been designed to overcome a particular behavior that happens in the latest Android phone. When an Android phone connects to an hostpot, it launches a “Sign in” webview that open the Welcome Portal. As soon as Android recognize that the user can reach internet , it closes automatically the “sign in with.. “ popup, and the user is dropped from the journey, making impossible to show other contents to the users.
This is a short video that shows an example of a standard journey on a phone where we see the "login" popup closing as soon as the user goes online, demonstrating the downfalls of the sign-up and login steps.
Sign-Up
This step happens when a new user registers for the first time. Also this trigger happens before the internet access authorization, so in this step the user is not online yet. The Sign-up trigger is then equivalent to the Login attempt, but it happens only the first time, when the user signs up to the WiFi service.
Other Triggers.
The Access Journey allows to publish app also after the actual network authorization (called "Login" trigger in the Access Journey orchestrator). However, this step never trigger on Android phones.
You can develop and host your app on your own servers, in any programming language.
When your app is invoked, Cloud4Wi will make a web call to your app's endpoint, appending a few parameters to the request, including a session key and other parameters.
For example, if your app is hosted on your server on a domain
https://myapp.mydomain.com
your app server will receive an HTTP call with the following structure:
https://myapp.mydomain.com?sk=skvalue&trg=trgvalue&opts=optsvalue&cburl=cburlvalue
There the list of parameters appended to the URL:
sk: is the session key. This parameter allows you to use the Context APIs to retrieve session context (info about the user, the location etc..)
tgr: this parameter include some values that represent the step of the Access Journey that invoked the app: - trOpn: Connect - trRgt: Sign up - trPlgn: Log in Attempt - trLgn: Log in - trLgt: Disconnect - false: When not part of the Access Journey
opts: this is a system value used by the Javascript SDK
cburl: this is the encoded value of the next step of the Access Journey. You can use this parameter to redirect the user to the next step of the Access Journey
Note that when your app is launched, the content is served directly from your application server and the browser is redirected on the domain where the app is hosted.
When the application is launched from the Splash Page in a stage when the user is not online yet, you need to make sure that your domain/hostname can be reached by the user by whitelisting your domain/hostname in the walled garden of the Access Point.
Each access point vendor has different capabilities, some of them can whitelist an entire domain with a wildcard, other supports only hostnames, and others support only a list of IP addresses (this last case, in particular, makes things much more difficult to handle if your hosting is in the cloud).
When the App is published in the Access Journey, you need to make sure to provide the users ways to navigate across the different steps of the journey. For example, if you publish a content in the Login Attempt, before the user is actually online, you need to embed in the app a method to let the user move forward to the next step, such as a button or an auto redirect.
MyApps offers several methods to handle this problem.
Using the Access Journey SDK, a client-side Javascript library
Using the cburl parameter in the GET
To learn more about the usage of the Javascript SDK, read the following Article:
Working with the Access Journey SDK
The SDK offers multiple methods to handle the navigation through the onboarding flow. Invoking simple methods such as MYAPPS.GoNext() allow to send the use to the next step of the journey without having to worry about carrying session data.
For example, you can easily create a button on your page that will call the GoNext method on click.
You can retrieve the url of the next step directly form the parameters in the GET. This allows you to handle the journey navigation also on the server side.
The parameter cbUrl in the GET is encoded, so you need to decode it to be able to use it.
Fore example, a server side redirect in PHP may look like this:
If you are workign on the client side, you can use the Javascript SDK method MYAPPS.getNextUrl();
