This recipe describes building an SPA (single page application) which uses an ATS as a back end in Talent App Store.
Before building the SPA, you'll need a tenant set up with an ATS inside it.
Note: when installing apps, the apps that have links are sandbox apps that you install via their install token - the other apps can be found publicly listed (find them with "Browse apps").
First, follow these instructions to install Developer ATS and create a job application. Then:
There are many ways to host SPA type apps, a thin server approach using nginx is shown below. In this example is is an SPA over an ATS.
In this approach SSO is used to protect web pages and API calls alike - the user must be signed in to do either.
Other approaches would be e.g. a gateway API server where the SPA code in the browser makes UI-specific API calls to the gateway, which then consumes TAS tenant APIs via tazzy as usual.
Here's a blow by blow of your web page loading and your SPA code making tenant API calls.
The user clicks on a link to visit a web page on your site.
The nginx instance sits behind SSO, so TAS now detects that the user is not signed in and redirects them to the identity app.
The identity app pops e.g. your OAuth dialog which asks the user to sign in.
Once the user is signed in, your identity app can perform additional checks e.g. that the user is allowed to see a specific job. If not, sign them out again.
After the user has signed in, they are redirected to the original page, which nginx now serves from your static content.
The SPA code in the page starts making same origin API calls, e.g. to fetch the applications for a job (http://devdocs.talentappstore.com/generated/recruitment.raml.html#applications_get).
The SPA code running in the browser starts making same origin API calls back to its own domain.
The API calls themselves are unauthenticated (have no secret key - the browser is in the hands of the enemy, we don't want to have any credentials there).
Because the user is signed in, SSO allows the API calls through to the nginx server.
The API call now reaches nginx as something like:
GET www.myats.com/t/acme/api/applications?job=1002
An nginx directive rewrites the url to this (the API format required by tazzy, as per the TAS programming guide.
GET myats.tazzy.io/t/acme/devs/tas/applications?job=1002
Another nginx directive attaches the app's secret key. By only attaching it at the back end like this, no credentials need be stored on the client.
nginx now proxies the rewritten API call onwards to tazzy.
The API call is complete!
When the SPA code receives http 302 redirect from any API call, it knows the SSO session has timed out and can e.g. reload the current page to force SSO again.
Whatever hosting approach you choose, you'll need to create an app at the developer site and install it in each tenant before they can use your SPA front end.
The SPA code can use the tazzy-saml request header to access email, name, image etc. for the signed in user (as set up by the identity app) as per the programming guide, e.g.:
GET /core/tenants/assertions/byKey/tazzy-saml/json
Response:
{
"nameID": "frank@ibm.com",
"entityID": "some other SAML info",
"tas.personal.givenName": "Fred",
"tas.personal.familyName": "Bloggs",
"tas.personal.email": "fredbloggs@gmail.com",
"tas.roles": [
"internal"
]
}