Jobs Data auto-login - Deprecatedđź”—
Please note that this feature is deprecated and will no longer be supported in the near future.
Introductionđź”—
Jobs Data auto login enables Jobs Data users to be automatically logged in to the Jobs Data web application from an external system using their Jobs Data credentials, to provide a “single sign-on” experience to the user.
Limitationsđź”—
- Jobs Data auto-login does not authenticate the user against a 3rd party user database.
- A Jobs Data account can optionally have multiple sub-accounts that can normally log in as [sub-account name]@[account name]. Auto-login can be used both on account and sub-account level. The auto-logged-in user will not be able to store or load saved searches, unless a UserID is passed from the external system on login.
- Jobs Data contains a feature where searches can be saved on account-level and shared with sub-account users. The sub-account user can not directly edit these searches, but can edit and save them under a different name for him- or herself (providing a UserID is passed on auto-login).
Auto-login processđź”—
Jobs Data autologin uses a challenge-response method that consists of three steps.
Important: All steps below need to be handled server side by the integrating party, up to the point where the user is redirected. Error handling also needs to be done at the side of the integrating party.
Step 1: Challengeđź”—
Send Jobs Data a challenge via a GET request with the Jobs Data (sub-)account name. Jobs Data will return a salt (string) via XML.
Description of the GET request:
| Field | Value |
|---|---|
| base_url | http://www.jobfeed.nl/autologin.php Replace www.jobfeed.nl with the country prefix of the Jobs Data country you wish to log in (e.g. uk.jobfeed.com or be.jobfeed.com) |
| action | challenge |
| accountname | The Jobs Data account name. Sub-account users should be provided as “user@account” |
Description of the XML response:
| Field | Description |
|---|---|
| autologin | Root element |
| salt | Contains the salt to be appended to the password before it is hashed. The salt has temporary validity. |
| error | One of the following. Empty if no error occured. - Account does not exist. - The requested search '[saved search name]' does not exist. |
| load | The name of the requested saved search to be loaded after login. Empty when not requested. |
Step 2: Login requestđź”—
You now request a login URL, by hashing the user’s password and optionally providing a user ID from the integrating system.
Description of the GET request:
| Field | Value |
|---|---|
| base url | Same as in the challenge request, e.g. http://www.jobfeed.nl/autologin.php |
| action | request |
| accountname | The Jobs Data account name, same as in the challenge request |
| passwordhash | The Jobs Data password appended to the salt (so: password.salt), hashed with MD5. |
| externaluser | A unique user ID from the integrating system. Optional but highly recommended. Needs to be provided to enable the user to save searches. It is also used to reuse a user’s previous session, to prevent users from running into the maximum number of concurrent logins limitation. The external user ID is uniquely identified in Jobs Data within an account or subuser (as part of an account). So different users can log in using the same credentials in Jobs Data, with different external user ID, have their own saved searches. |
Description of the XML response:
| Field | Description |
|---|---|
| autologin | Root element |
| redirect | Contains the URL the user should be redirected to, in order to be logged in. The redirect URL has temporary validity. |
| error | One of the following. Empty if no error occured. - Invalid username/password specified - The challenge has expired - This account has been disabled - This account has expired |
Step 3: Redirectđź”—
Redirect the user to the provided URL.
Example codeđź”—
Example code in PHP is available and can be provided on request.