You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we have an issue with the amount of manual work required with updating the redcap urls in the config whenever the redcap versions are updated as the urls contain redcap version numbers (like https://redcap-phidatalab.brc.iop.kcl.ac.uk/redcap_v13.1.27/). This is not scalable and hence we need to move to using the base domain name verification and the redcap version can be anything in that case. But this causes issues if there are more than one redcap is hosted on a single domain. This thread suggests mitigations for that.
We should verify that the token provided can actually access redcap form before we generate a subject on management portal to avoid inconsistencies since later the app may not be able to update the redcap form if the token is not valid for the redcap project being updated. Ideally, this should be enabled (disabled by default) with a property like preverify_redcap_access: true since we do have some studies where redcap is not accessible and they are happy with a one way integration with management portal.
I think this would be quite useful when we move to validation of url to just use a domain name instead of full url, as it would allow us to avoid incorrect use of redcap + mp mapping if more than one redcap is hosted on a single domain as the token for projects would ideally be different and we will not be able to access redcap if it is incorrectly mapped.
What do you think @afolarin and @mpgxvii ?
The text was updated successfully, but these errors were encountered:
Additionally, we can also add a key to map the redcap versions on a single deployment, allowing integration for mutiple redcaps from a single domain. If this key is not specified, it would fail as mentioned above.
Use API key to check project access to disambiguate projects on the TLDN (although this wouldn't work if you had multiple versions of a project on multiple versions of REDCap deployed on different version URL paths).
Have a Key or Code in the radar-integration form that could be used to disambiguate projects on the TLDN.
Currently, we have an issue with the amount of manual work required with updating the redcap urls in the config whenever the redcap versions are updated as the urls contain redcap version numbers (like
https://redcap-phidatalab.brc.iop.kcl.ac.uk/redcap_v13.1.27/
). This is not scalable and hence we need to move to using the base domain name verification and the redcap version can be anything in that case. But this causes issues if there are more than one redcap is hosted on a single domain. This thread suggests mitigations for that.We should verify that the token provided can actually access redcap form before we generate a subject on management portal to avoid inconsistencies since later the app may not be able to update the redcap form if the token is not valid for the redcap project being updated. Ideally, this should be enabled (disabled by default) with a property like
preverify_redcap_access: true
since we do have some studies where redcap is not accessible and they are happy with a one way integration with management portal.I think this would be quite useful when we move to validation of url to just use a domain name instead of full url, as it would allow us to avoid incorrect use of redcap + mp mapping if more than one redcap is hosted on a single domain as the token for projects would ideally be different and we will not be able to access redcap if it is incorrectly mapped.
What do you think @afolarin and @mpgxvii ?
The text was updated successfully, but these errors were encountered: