Do not persist the jupyter baseUrl in pipelines

[ajbozarth]

The changes in #2728 cause the pipeline-editor to persist the full
url for a node's image. This could cause issues with surfacing PI,
as such I've updated that fix to instead use the full URL path,
which will behave the same as before the fix, but including the
URL path from the baseUrl if one exists.

Note that if a baseUrl path conatains PI that would still be
persisted, but putting PI in a URL path is considered inappropriate
handling of PI by the server owner, not Elyra.

Fixes #2773

Developer's Certificate of Origin 1.1

   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

[elyra-bot]

Thanks for making a pull request to Elyra!

To try out this branch on binder, follow this link:

[marthacryan]

Code LGTM but I haven't tested locally

[kevin-bates]

LGTM. Confirmed entries change:
ui_data entry goes from ...

            "ui_data": {
              "label": "Calculate data hash",
              "image": "http://localhost:8888/static/elyra/kubeflow.svg",
              "x_pos": 37,
              "y_pos": 364.5
            }

to

            "ui_data": {
              "label": "Calculate data hash",
              "image": "/static/elyra/kubeflow.svg",
              "x_pos": 37,
              "y_pos": 364.5
            }

[ajbozarth]

Also as a note due to how this field is handled this will also update any pipeline that is opened/edited, so there no worry about pipelines that already persisted the full url with a domain or ip

[ptitzler]

Note that if a baseUrl path conatains PI that would still be
persisted, but putting PI in a URL path is considered inappropriate
handling of PI by the server owner, not Elyra.

A user might not necessarily have control over this. For example, Elyra deployments running as Kubeflow Notebook Server the URL is
http://<host-domain>:<port>/notebook/<kubernetes-namespace>/<user-provided-name>/static/elyra/kubeflow.svg:

The namespace is something an administrator configures, not necessarily the person who deploys Elyra as a notebook server.

[kevin-bates]

@ptitzler - that's a good point. Couldn't we persist the "suffix portion" and strip anything prior to static/elyra? Then, these values are identical across pipelines and independent of base_url.

[ajbozarth]

Couldn't we persist the "suffix portion" and strip anything prior to static/elyra

That was the behavior prior to my fix that caused this, so that would just revert the fix and bring back the issue it solved.

Overall this is a limitation of canvas not elyra, and if including any of the baseUrl is a problem then we will just need to return to using base64 encoded strings for the images like we did before moving them to the server

[ptitzler]

LGTM. Confirmed that host/domain/port information is no longer persisted in the .pipeline file. We should follow up in the future and implement a solution that does not expose potentially sensitive information that might be included in the URL path. Example value for an Elyra deployment on a Kubeflow Notebook server:

/notebook/kubeflow-user-example-com/test2/static/elyra/kubeflow.svg

[lresende]

Note that, storing environment-specific details, such as host+port also breaks the ability to share the pipelines with others.

[ptitzler]

Note that, storing environment-specific details, such as host+port also breaks the ability to share the pipelines with others.

Right, that concern was why I've created the issue in the first place! In this specific case though it turns out it doesn't impact portability of pipeline files between environments. We definitely need to continue to watch out for these things.