devfile-registry: python-django app cannot preview

[sunix]

Describe the bug

Python Django devfile cannot preview the application.

Che version

• latest
• nightly
• other: please specify

Steps to reproduce

1. Start the Django Python devfile from the Get Started Page
2. Run these commands:
   • set up venv
   • install dependencies
   • migrate
   • run server
3. Che propose to open the preview
4. the preview fails to connect
5. Opening in a new tab works fine

Expected behavior

It should show the right page in the preview panel

Could be fixed by setting X_FRAME_OPTIONS to allowall.

  - name: run server
    actions:
      - workdir: '${CHE_PROJECTS_ROOT}/django-realworld-example-app'
        type: exec
        command: |
          . ${CHE_PROJECTS_ROOT}/.venv/bin/activate && export DEBUG_MODE=False && cp conduit/settings.py local_settings.py && echo "X_FRAME_OPTIONS = 'ALLOWALL'" >> local_settings.py && python manage.py runserver --settings local_settings 0.0.0.0:7000
        component: python
  - name: run server in debug mode
    actions:
      - workdir: '${CHE_PROJECTS_ROOT}/django-realworld-example-app'
        type: exec
        command: |
          . ${CHE_PROJECTS_ROOT}/.venv/bin/activate &&  export DEBUG_MODE=True && && cp conduit/settings.py local_settings.py && echo "X_FRAME_OPTIONS = 'ALLOWALL'" >> local_settings.py && python manage.py runserver --settings local_settings 0.0.0.0:7000 --noreload --nothreading
        component: python

Runtime

• kubernetes (include output of kubectl version)
• Openshift (include output of oc version)
• minikube (include output of minikube version and kubectl version)
• minishift (include output of minishift version and oc version)
• docker-desktop + K8S (include output of docker version and kubectl version)
• other: (please specify)

Screenshots

Installation method

• chectl
  • provide a full command that was used to deploy Eclipse Che (including the output)
  • provide an output of chectl version command
• OperatorHub
• I don't know

Environment

• my computer
  • Windows
  • Linux
  • macOS
• Cloud
  • Amazon
  • Azure
  • GCE
  • other (please specify)
• Dev Sandbox (workspaces.openshift.com)
• other: please specify

Eclipse Che Logs

Additional context

[vitaliy-guliy]

Django replies with x-frame-options: DENY HTTP header.
It block opening a page inside iframe.

I disabled django.middleware.clickjacking.XFrameOptionsMiddleware module, that adds the header and the sample become working.

There is a PR che-samples/django-realworld-example-app#3 removing the middleware from Django sample.

[tsmaeder]

Since @vitaliy-guliy involved me, I'll chime in: IMO, the question is whether blocking usage in a frame is good security practice or not: we don't want to give a bad example. If that is so, the fact that it doesn't work in the preview is a feature, not a bug. If it's not security relevant, by all means let's allow-all,

[vitaliy-guliy]

Since @vitaliy-guliy involved me, I'll chime in: IMO, the question is whether blocking usage in a frame is good security practice or not: we don't want to give a bad example. If that is so, the fact that it doesn't work in the preview is a feature, not a bug. If it's not security relevant, by all means let's allow-all,

The doc says that only DENY and SAMEORIGIN allowed for the header https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

With SAMEORIGIN it will not work since Che-Theia and python http server are running inside other container have different domains.

There is also a simple doc describing the logic of the module https://docs.djangoproject.com/en/1.11/_modules/django/middleware/clickjacking/

Trying with allow-all, just to test..

[vitaliy-guliy]

@tsmaeder it works fine with allow-all.
This is none-standard value (https://en.wikipedia.org/wiki/Clickjacking#X-Frame-Options), browser just ignores it.

The PR che-samples/django-realworld-example-app#3 is updated

[ericwill]

Fixed by che-samples/django-realworld-example-app#3

[sunix]

I would not make any modifications on the original sample: the fork is just to prevent changes that may break our devfiles. the more we fork, the harder it would be to maintain. I would rather set xframe-options in the Che command as suggested in the description.
If the application is not supposed to be running in a frame, we shouldn't change it. Imagine this being a real app: the frame should be allowed only in dev mode (in Che) not in production.