PRICING

HELP

BLOG

APPSTORE

COMPANY

LEGAL

LOGIN

AI Assisted Content Management System

Analytics & Lead Generation

Automation Projects

Browser Extension Apps

Dashboard Theme Analysis: LN1

Data Exchange Automation Tools

Getting Started With Building Hybrid Apps

Izyware Hybrid UX Design Guidelines

Onboarding New Organizations Using Izyware

Quick Visualization and Monitoring

Unified Metrics Stream Pipeline

Legacy Features and Backward Compatibility

How does the legacy frame architecture work

Izyware Legacy UI Circus Engine

Case Studies and Knowledge Center

Angular and React Embedding Guide

Build and deploy a content distribution app in less than five minutes: Part II

Comparison of CSS Preprocessors SASS vs LESS vs STYLUS

Comparison of node.js test frameworks and utilities: lab, chai, sinon

Manage and automate your day to day business tools using IzyCloud Tasks: Part I

MySql Performance Optimization

Onboarding Tutorial: Creating & publishing an app

Rebranding and Customizing Websites

Using IzyCloud on Android: IzyCloud Query App

Technical Resources

.NET SDKCore IzyWare

av-stream README

ElasticSearch IzyWare Data Console Feature

End To End Testing

End To End Testing, Part II

frames and nav (ui/w/shell/navmulti) README

izy-circus README

izy-idman-tools README

izy-pop3 README

izy-proxy README

izy-sync README

IzyIDE README

izymodtask readme

IzyShell readme

ReKey Feature Package README for IzyWare SQL Console

Single Sign-On (SSO) README

Tasks Migration : V5 guidelines

Users & Groups README

V5 Migration : apps/pulse guidelines README

Container Orchestration

Izy Kubernetes Internal Networking Troubleshooting

Application Hosting

Content Publisher

Domain Registration

Email Hosting

Izyware Browser Extension

Izyware Deployment Engine

Izyware Session Management

Messaging System APIs and functionality

Single SignOn

Integration APIs

iOS SDK

Azure and .NET

izy-devops

<< Izyware Deployment Engine

Messaging System APIs and functionality >>

Izyware Session Management

This article describes the Izyware Session Management system

Introduction

Any multiuser system needs to be able to authenticate, authorize and control the access to its features and resources.

While currently cookie based authenticatation is the predominant method of implementation, it relies heavily on the domain based security rules implemented by modern browsers. This model would cause challenges when implementing apps in hybrid environments.

Credential Lifecycle Management UI

The full life cycle for signing up (create), authenticating (read), updating username/password (update) has been implemented in a self contained package. It is worth mentioning that token persistence has been intentionally decoupled from this package to allow for flexible use in a variety of scenarios (cross-domain, toolbar, embedded, etc.).

push(["overlay", {

"parts" : "ext",

"what" : "ui/w/shell/login/full",

"initval" : {

"node" : modtask.node

},

"success" : [

["query", false, "val", modtask, "user"],

function(push) {

modtask.modsess.setUser(

modtask.user,

function() {

push([

["push", "onuserstate", modtask]

]);

}

);

}

]

}, modtask] );

modtask.modsess os the interface that should provide sessions persistence via setUser/getUser interface. Below are a few examples.

Session Agnostic Frames

The frame will query for the modsess:

doChain(

['frame_getsessman', modtask],

function() {

modtask.sessman.getUser(

function(user) {

}

The frame does not really care how the session is managed. The advantage of this approach is that the UI can be reused in the following scenarios:

Regular Website

case 'frame_getsessman':

params['sessman'] = modtask.ldmod('ui/w/shell/sessman/ckbased').sp({

node: modtask.getNode()

});

callback(transition);

return true;

break;

Toolbar

In a browser toolbar implementaion mode, the cookie based persistence would not be appropriate and instead the global api is used to persist the user object:

case 'frame_getsessman':

params['sessman'] = {

getUser: function(okpush) {

modtask.getGlobal('user', function(val) {

if (!val) val = false;

okpush(val);

});

}

}

callback(transition);

return true;

break;

Case Study: Embedded Widgets -- Login Wall

The embedded login wall which is useful for scenarios where the application functionality needs to be made available only to authenticated users (i.e. most of the appid/register/embedded) use the cookie based sesssion manager.

modtask.sessionCheck = function(push) {

push({

parts: 'ext',

what: 'ui/w/shell/auth/simple',

onuserstate: [

function(push) {

push(['replace', modtask.statusInstructions])

}

]

})

}

The problem with the current implementation for auth/simple is that it does not decouple the session from its implementation and uses ckbased hardwired. A better approach would be to decouple it. Also to make it work cross domain, a new session manage type would need to be created that would rely on iframes (the iframe would store the cookie and would be on the izyware.com or another trusted thirdparty site) and window messaging for communicating state.

Resource Access

\ui/node/direct\ is the main component that is used to access cloud resources.

var node = modtask.ldmod('ui/node/direct').sp({

// Optional: What sort of access do I have? false means minimal

accesstoken: false,

// Where is the service located at?

dataservice: 'https://izyware.com/',

// Optional: If using tunnelling to access resources, pass the id

tunnelendpointid: 'endpointid',

// What communication stack should I use?

groupidobject: {

transportmodule: 'qry/transport/scrsrc'

},

// log queries, etc.

verbose: true,

// default is true

encryptqueries : false

});

All the other servies, including the identity management system use:

node.runQuery2(

q,

okpush,

failpush

);

Authentication

The following steps are used for generating an authentication token:

Step 1

A username/password is all that is needed to obtain an authentication token. For example, ui/w/shell/login uses the following to login a new user:

modtask.ldmod('ui/node/api/user').sp({

node: node

}).authenticate({

user : 'username',

password : 'password'

},

function(user) {

// pass user.accesstoken to your node object

},

function(outcome) {

}

);

If successful, this will return a user object which will have the information about the user (role, etc.) and also the authentication token.

Step 2

The authentication token may be used to request privilaged services via the \accesstoken\ property of the node object.

node.sp('accesstoken', user.accesstoken).runQuery2(

...

);

Persisting the Session

Unless running in an extension or a mobile app, the session token needs to be persisted in order to avoid login attempts from happening everytime the the page is refresh.

Case in point is the Shell. After the user is logged in successfully, it uses he \rel:session\ to cookie the current web domain container:

"success" :

[

["query", false, "val", modtask, "user"],

function(push)

{

modtask.ldmod("rel:session").setUser(

modtask.user,

function()

{

push(["push", "onuserstate"]);

}

);

}

]

WARNING BUG: for backwards compatibility, it also performs:

modtask.ldmod("ui/node/auth").set(user.accesstoken) action.

This will force sign all the node instances to use the user.accesstoken which will cause issues in a multi node environment. See the workarounds section for solutions.

When the Shell is loaded due to entering the page or refresh, it will call:

modtask.ldmod("rel:session").getUser(function(user) { })

This will perform the following checks:

• If a \cached\ user is defined, just return it, otherwise
• If the \setUser\ cookie is not defined return no user, otherwise
• Extract the accesstoken from the the cookie and load user information by:

modtask.ldmod("ui/node/api/user").sp({ node : modtask.node }).loadsession(

{ "accesstoken" : accesstoken },

function(user) {},

...

Sharing Scenarios

temporary accounts

The sharer sends a user agnostic* link to sharee.

- when landing on the link, if the session is logged in access will be granted to that session

- if not logged in you can either

- force login/account create

- use temporary accounts to allow temporary access

the sharer sends a sharee specific* link to sharee

- because this assumes the sharee is already in the system, if logged in as the sharee it will just work, otherwise if logged in as somebody else or not as sharee it will force them to relogin as the new user.

Links

• package bootstrap/5/sessman

Change Log

V5.3

• 530045: add api?login

* replaces sendmail,user,' + commaEncode(params.user) + ',' + commaEncode(params.password) + ',5'; for runQuery2

* fixes security issues reported for \

* lower cases and white space cleanses the username before auth

V5

• add api?whoamifull

* populate session user information from usermetadata

• add usermetadata data schema
• add api?whoami