Currently, UI Plugin infrastructure works in the following way: - upon WebAdmin GUI login, take GUI (admin) user credentials and initiate (one) REST API session - broadcast received (single) session ID to all UI plugins Despite very simple, this approach has following disadvantages: - when UI plugin talks with REST API via session ID, the session has exact same privileges as GUI (admin) user - having only one REST API session, some evil UI plugin can close the session (enforce logout) which can compromise behavior of other UI plugins This RFE essentially suggests replacing "One [admin-gui-user] session for all plugins" with "One [plugin-user] session per each plugin" approach. Design proposal: 1. when processing WebAdmin GWT application request (server-side) - during UI plugin discovery phase: - check if the given plugin explicitly enabled REST API integration (boolean) via its metadata/config - if yes, load username/domain/password credentials + permissions (REST API integration user) via its metadata/config - validate above mentioned user credentials, create user if it doesn't exist yet - synchronize permissions from plugin metadata/config with given user, i.e. update permissions for that user 2. when processing WebAdmin GWT application request (server-side) - during embedding plugin data into HTML phase: - eagerly create REST API session for the user specified in previous step (REST API integration user) - embed REST API session ID into runtime plugin information, no user credentials allowed here! 3. when starting up WebAdmin GWT application (client-side) - during UI plugin load phase: - pass REST API session ID to given UI plugin via UiInit function - this means RestApiSessionAcquired is not necessary anymore, since session creation is not asynchronous from client perspective What we gain: - each UI plugin will have its own dedicated REST API session, unrelated to GUI (admin) user credentials - each UI plugin can (must) explicitly define permissions it requires with regard to REST API integration - for each UI plugin, we can selectively enable/disable REST API integration as necessary (useful for WebAdmin end-users) - we don't have to keep-alive the single "shared" session anymore, because there will be no "shared" session anymore Potential issues: It might be difficult to create REST API session from within server-side code, I'd really like to avoid doing "Engine -> HTTP request -> Engine" cycle.
CC'ing Michael, maybe it's worth revisiting support for passing session ID (i.e. JSESSIONID value) in a way other than HTTP cookie. This would allow UI plugin code (JavaScript) to communicate directly with Engine REST API. Using JSESSIONID cookie is most likely impossible because REST API expects this cookie to be set for path=/api and plugin code runs under path=/webadmin -> worth giving a try, though. (maybe we can try setting the cookie for the root path)
(In reply to vszocs from comment #3) > (maybe we can try setting the cookie for the root path) Bad idea, since there are different JSESSIONID cookies for different applications, depending on cookie path.
Target version?
Target version = future for now, currently low priority To summarize positive impacts of this RFE: 1. isolation -> each UI plugin will have its own REST API session assigned, i.e. avoid single shared session and issues that come with it 2. transparency -> each UI plugin will have to state permissions for its REST API session explicitly, i.e. permissions unrelated to admin GUI user 3. control -> we can disable REST API session functionality per each UI plugin if necessary 4. simplification -> no need for "keep-alive single shared session" functionality anymore
We should consider following items for this RFE: - have one REST session per UI plugin (which also means creating associated Engine user for this purpose) -> plugin vs. plugin REST session isolation - create REST session not from client (WebAdmin/JavaScript) but from server (when serving WebAdmin.html) -> avoid issues with cookies [*] & HTTP Basic Auth handling [**] [*] multiple-cookies (one per UI plugin) with same name (JSESSIONID) for same origin (REST API) is not possible [**] browsers usually cache HTTP "Authorization" request header for given origin (REST API) which complicates authentication from plugin perspective
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.