...
To edit the whitelist when the web client is hosted in Apache you will need to edit the values within the proxy.php file. At the top of the file will be a PHP variable called $WHITELIST which will contain an array of URLs. You will need to enter the protocol, hostname and port (if any) for all i2b2 hive services that the web client will need access to. You can see an example of a proper whitelist configuration below:
...
...
...
...
"http://services.i2b2.org", |
...
...
...
...
...
...
...
| Anchor |
|---|
| _zdec521nyfc5 |
|---|
| _zdec521nyfc5 |
|---|
|
Blacklist in ApacheIn the PHP proxy service file (proxy.php) you will also have the ability to set blacklist entries. These entries will prevent proxying of any requests whose URLs begin with any of the values listed in the $BLACKLIST variable. You can see an example of a proper blacklist configuration below:
...
| Code Block |
|---|
$BLACKLIST = array(
"http://127.0.0.1:9090/test", |
...
"http://localhost:9090/test" |
...
Security Check Each i2b2 Request in ApacheIt is possible for you in Apache to run a security check against the Project Manager for each i2b2 request. These options are within the proxy.php file as follows:
| Code Block |
|---|
|
$pmURL = "http://127.0.0.1:8080/i2b2/rest/PMService/getServices"; |
...
$pmCheckAllRequests = true; |
The $pmURL variable should be set to the URL used to validate the security credentials in the request before it is forwarded on to the requested cell service. It usually ends in "/getServices".
The $pmCheckAllRequests variable is used to turn on or turn off the extra per-request security check. It is a boolean value and should be set to true or false only.
...
In addition to configuring the web server and proxy service you will need to configure the i2b2 domain instance within the web client. Once again, all i2b2 domains are configured within the i2b2_config_domains.json file. Specifically you will need to add a "saml" object within the SAML-enabled domain entry. Within the saml object will be another object named with the name of the SAML-enabled service (for example "shibboleth" as shown below). When you are using the NodeJS-based proxy server you can set the value of the object to true or null. When hosting your web client deployment under Apache you will need to specify the URLs for the redirect and logout services within the saml object. Example configurations are as follows:{
| Code Block |
|---|
|
{
"urlProxy": " |
...
...
"urlFramework": "js-i2b2/", |
...
...
...
...
"name": "Shibboleth (localhost)", |
...
"urlCellPM": "http://127.0.0.1/i2b2/services/PMService/", |
...
...
...
...
...
{
"redirect": "saml-redirect.php", |
...
"logout": "saml-logout.php" |
...
...
| Anchor |
|---|
| _g5ua8mdsddi6 | | _g5ua8mdsddi6 |
|---|
|
I2B2 CONFIGURATION...
When the i2b2 web client is loaded into a web browser it loads the configuration file i2b2_config_domains.js located in the root of the hosting directory. This file contains (among other things discussed below) an entry called urlProxy that configures the URL that the web client will use to access the proxy service to communicate with the i2b2 hive. By default the is configured for self-hosting using the NodeJS i2b2-webclient-proxy server. To host the web client under Apache you will need to change this from the default as shown below:.
For hosting via NodeJS{
| Code Block |
|---|
{
"urlProxy": "/~proxy", |
...
"urlFramework": "js-i2b2/", |
...
...
...
For hosting via Apache + PHP{
| Code Block |
|---|
|
{
"urlProxy": "/proxy.php", |
...
"urlFramework": "js-i2b2/", |
...
...
...
...
All configurations to connect to i2b2 servers are stored within the configuration file i2b2_config_domains.js and are contained within the lstDomains array. By default a connection to the demonstration server at http://services.i2b2.org is configured for testing purposes and is shown below:{
| Code Block |
|---|
|
{
"urlProxy": "/proxy.php", |
...
"urlFramework": "js-i2b2/", |
...
...
...
[
{
"domain": "i2b2demo", |
...
...
"urlCellPM": "http://services.i2b2.org/i2b2/services/PMService/", |
...
...
...
...
...
...
The domain value contains the domain name that is configured within an i2b2 instance.
The name value contains the text that is displayed in the login window for the user to identify the instance.
The urlCellPM value contains the URL that is used to contact the i2b2 server which contains the configured domain. The hostname of the server must also be added to the whitelist configuration used by the proxy service. See the related whitelist documentation in the NodeJS/Apache Hosting section.
The allowAnalysis boolean value configures whether a user will be able to use analysis plugins when logged into the i2b2 domain.
The debug boolean value configures whether the user will be able to use debugging tools when logged in. This value is deprecated and will be removed in the future.
| Anchor |
|---|
| _bu31k6mwi24l |
|---|
| _bu31k6mwi24l |
|---|
|
| Anchor |
|---|
| _qi60v4li9m81 |
|---|
| _qi60v4li9m81 |
|---|
|
...
For plugins to operate properly when hosted by Apache you will need to manually edit a file called plugins.json that exists within the root /plugins directory containing an array of plugin names as shown below.
| Code Block |
|---|
[
"edu.harvard.catalyst.example", |
...
"edu.harvard.WeberLab.ExportPatientset" |
...
If you are using the i2b2-webclient-proxy service to host your web client UI it will automatically generate the plugins.json file based on the directory structure if the file does not exist (not manually created). The Github repository for this proxy server is at _https://github.com/hms-dbmi/i2b2-webclient-proxy_
| Anchor |
|---|
| _hiu9medlpxn4 |
|---|
| _hiu9medlpxn4 |
|---|
|
...
Just like in the legacy web client, any plugins that are added must have an entry within the i2b2_loader.js file that is in the root of the execution environment. This file would be located at /js-i2b2/cells/LEGACYPLUGIN/legacy_plugin/js-i2b2/i2b2_loader.js with an example listing of the configuration lines shown below:
| Code Block |
|---|
|
//==========================================================================// |
...
// THESE ARE ALL THE CELLS THAT ARE INSTALLED ONTO THE SERVER |
...
...
...
...
...
...
...
{ code: "PLUGINMGR", ...}, |
...
...
...
...
| Wiki Markup |
|---|
{*} params: \[\] \},* |
...
roles: [ "DATA_LDS", "DATA_DEID", "DATA_PROT" ], |
...
forceDir: "cells/plugins/standard" |
...
...
...
...
...
| Wiki Markup |
|---|
{*} params: \[\] \},* |
...
roles: [ "DATA_LDS", "DATA_DEID", "DATA_PROT" ], |
...
forceDir: "cells/plugins/community" |
...
...
//==========================================================================// |
Each plugin will have a configuration object within the defined i2b2.hive.tempCellsList array variable. The meaning of the configuration object's attributes is as follows:
The code attribute is the name of the plugin as well as the name of the directory containing the plugin's code and assets.
The forceLoading attribute notifies the legacy i2b2 plugin execution environment that the plugin should be loaded upon environment creation. For the plugin to work correctly this must be set to true.
The forceConfigMsg attribute contains configuration information that is passed to the plugin. It is an object which must contain an array named params.
The roles attribute contains the roles which can use the plugin. The rolls are as follows: DATA_OBFSC for Obfuscated, DATA_AGG for Aggregated, DATA_LDS for Limited Data Set, DATA_DEID for De-identified Data, DATA_PROT for Protected.
The forceDir attribute points to the parent directory that the plugin's directory exists within.
...
https://github.com/hms-dbmi/i2b2-webclient-proxy
...
| Anchor |
|---|
| _qrvsxe4i2xo6 | | _qrvsxe4i2xo6 |
|---|
|
Acknowledgments...
