The official names of the EDRN Collaborative Groups (as dictated by the DMCC) are these terms exactly:

• Breast and Gynecologic Cancers Research Group
• G.I. and Other Associated Cancers Research Group
• Lung and Upper Aerodigestive Cancers Research Group
• Prostate and Urologic Cancers Research Group

What I'm currently seeing in EDRN LabCAS Solr is:

• Breast and Gynecologic (missing "Cancers Research Group") ❌
• Breast/GYN ❌
• GI and Other Associated (missing periods, "Cancers Research Group") ❌
• Lung and Upper Aerodigestive Cancers Research Group ✅
• Lung and Upper Aerodigestive (missing "Cancers Research Group") ❌
• Lung and Upper Areodigestive (misspelled "aerodigestive", missing words) ❌
• Not Applicable (not a collaborative group) ❌
• Prostate and Urologic (missing "Cancers Research Group") ❌
• TBD (not a collaborative group) ❌

I think LabCAS may want to strive for some consistency here. The CancerDataExpo and EDRN Portal will have special case code to work around these issues for now.

Create a collection in EDRN LabCAS for Benign Breast Disease Pathology Slide Images - linked to the BBD protocol (id – 331) and DCIS protocol351

Create two datasets under this collection.

1. The first dataset would have the original images (access limited to DMCC, JPL, NCI – per Jackie email 1/25/20)

2. The second dataset would have the de-identified images (Nobody should have access until DMCC receive the biomarker results from Andy Godwin. Once we have that, then I think we are providing access to Case Western (Bera Kaustave) along with clinical data linked to the images. per Jackie email 1/25/20)

Link images to appropriate protocol id (first 3 digits of ID)

JPL security has issued a SPL against LabCAS backend in the Tomcat component.

It needs to be secured as per: https://cutt.ly/DN5TUnw

In addition, on edrn-labcas, Tomcat must be upgraded to 9.0.68.

JPL NetOps has discovered a potential security issue and has filed a Security Problem Log (SPL), report Q1580668, on the /data-access-api endpoint of the LabCAS backend.

The issue is that CORS is allowing too many to possible connection origins and we need a more restrictive Access-Control-Allow-Origin header.

The report tested the https://edrn-labcas.jpl.nasa.gov/data-access-api/collections/select endpoint with the following query

GET /data-access-api/collections/select?q=*:*&wt=json&indent=true&rows=10000&sort=id%20asc HTTP/1.1

as being too permissive. It also discovered the problem on the following URLs:

• https://edrn-labcas.jpl.nasa.gov/data-access-api/collections/select
• https://edrn-labcas.jpl.nasa.gov/data-access-api/datasets/select
• https://edrn-labcas.jpl.nasa.gov/data-access-api/download
• https://edrn-labcas.jpl.nasa.gov/data-access-api/files/select

Suggested Fix

JPL says that "Overly Permissive CORS Access Policy Remediation Issue Types that this task fixes Overly Permissive CORS Access Policy GeneralPrepare a list of trusted sites, and set them as the value of the ""Access-Control-Allow-Origin" header.If there is no need for external access, remove this header completely."

Robert Solorio says /data-access-api/auth cannot accept GET requests, even though the credential is base64-encoded.

Instead, it must only use POST requests, where the credential is plainly visible.

Because "reasons" 🤔