Opne DACS Java API - Need to implement login and Logout separately.
I need to integrate a consumer application to DACS through middleware tool. The requirement is :
Login to DACS infra with certain details like : Username, ApplicationID, Position, PE etc..
Logout only when logout request is made fro consumer application.
I'm following open DACS Java API to connect to DACS Daemon and Login to DACS Infrastructure. I'm following the exactly the same step and code which is available in Tutorial 4 - Content Based Entitlements (CBE)
Here, in tutorial, the logout action is performed after CBE check :
client.login();
client.waitForCallBackEvent(5);
client.checkSubCBE();
client.waitForCallBackEvent(5);
client.logout();
Instead of that,I need to do a separate call to logout a user.
Please guide.
Pimchaya.Wongrukun
There need to be separate API call like below :
Looks like below :
1. xyz.com/dacs/getEntitlements
This API should performs upto the following :
client.login();
client.waitForCallBackEvent(5);
client.checkSubCBE();
i.e login, and check CBE.
Now, once the API gets response it will lost all the details for the current user who logged in. As the API is stateless.
2. xyz.com/dacs/{user}/logout
This should perform logout.
Now my concern here is that, while calling logout, _agent, and _handle instance required (_agent.logout(_handle);) . And logout as a separate API, we can't pass that from request.
Best Answer
-
Hello @Balwant
The application can logout after it requests/consumes data. This depends on your requirements when you wish to log out after logging in. Please refer to Tutorial 5 - Integrating DacsClient with StarterConsumer, it shows how to integrate openDACS Java API with consumer application. The tutorial logs out after it gets data message (refresh message) to get DACS lock to check if a user has permission to access data against the user's profile or not.
0
Answers
-
Thanks @Pimchaya
In tutorial 5 I can see it is returning a boolean succeessfullyLoginDACS which returns true or false. Also, DACS lock is obtained during Performing SBE check and subscribe item and then CBE check happens and finally logout. This all happens during one request.
In my scenario, Login an entitlement check, and logout will be separate request.
The workflow will be :
User requests logsin : Login- > Entitlement status return as true/false. (Call CBE)
User request logout : Logout -> User logged out returned (call logout)
For example faceboo/gmail
0 -
Hello @Balwant
To login, in DacsSubscribeClient.login() it calls
_handle = _agent.login(_dacsEventQueue, request, this, null);
To perform SBE check, in DacsSubscribeClient.checkSubSBE() it calls:
AuthorizationCheckResult authCheckResult = _agent.checkSubscription(_handle, _usage, reqType,authCheckStatus, _serviceName, _itemName);
To subscribe item, in ItemManager.sendRequest() it calls
Handle itemHandle = _mainApp.getOMMConsumer().registerClient(_mainApp.getEventQueue(), ommItemIntSpec, this, null);
To check CBE, in DacsSubscribeClient.checkSubCBE(..) it calls
authCheckResult = _agent.checkSubscription(_handle, _usage,_reqtype,authCheckStatus, false,_serviceName, _itemName, dacsLock);
All are done by difference methods/difference requests. The application can calls the methods separately. For example, you can create an application containing a login button and a logout button. When a user clicks the login button, the application calls DacsSubscribeClient.login() and DacsSubscribeClient.checkSubCBE(..). When a user clicks the logout button, the application calls DacsSubscribeClient.logout().
If my explaination above does
not serve your requirement, what one request do you mean?Does it mean the same
_handle instance are used in performing login, checking SBE/CBE and logout?0 -
My concern is that for logout what parameter I need pass. How logout wil understand which user to logout?
0 -
Hello @Balwant
To log out for a user, the handle(an instance of Handle class) of the user is required as shown below:
_agent.logout(_handle);
Please refer to DacsSubscribeClient.logout()
which demonstrates how to log out a user._handle is previously obtained
from logging in the user as shown in DacsSubscribeClient.login():_handle = _agent.login(_dacsEventQueue, request, this, null);
The application should keep each user’s handle returned when logging in.
When a user requests to log out, call logout function with the user’s handle. Hence, logout
will understand which user to logout.In addition, to perform SBE or CBE check, a user’s handle is
required as well:To perform SBE check:
authCheckResult = _agent.checkSubscription(_handle, _usage, reqType,authCheckStatus, _serviceName, _itemName);
To perform CBE check:
authCheckResult = _agent.checkSubscription(_handle, _usage,_reqtype,authCheckStatus, false,_serviceName, _itemName, dacsLock);
Hence, performing SBE/CBE check will understand which user requests to perform it.
The application should keep the user name and his handle for each user. Hence, it can perform
SBE/CBE check or logout whenever any user requests properly by passing the
handle of the user who requests to perform that action.Open DACS API provides the interfaces to perform login, SBE/CBE check and logout to DACS. Managing users' session(when a user logs in/logs out) or users' info e.g. handle is the responsibilities of the application not Open DACS API.
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 689 Datastream
- 1.4K DSS
- 626 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 277 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 706 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛