search

ixc / wagtail-instance-selector

A widget for Wagtail's admin that allows you to create and select related items
MIT License
54 stars 17 forks source link

127.0.0.1 refused to connect. #5

Closed Redhaus closed 4 years ago

Redhaus commented 4 years ago

hello sir,

I am having an issue. the modal window loads

but rather than loading the model data it says 127.0.0.1 refused to connect.

All of my other chooserpanels work fine.

Do you have any ideas why that would be the case? I am not getting any errors or anything.

Any direction you can provide would be much appreciated.

Thanks

Redhaus commented 4 years ago

Hello sir,

I figured out what the issues is but do not know the cause. When running on django version 2.1.15 everything works perfectly with your model chooser

However, when running on django-3.0.4 I get the blank modal that reads "127.0.0.1 refused to connect." Do you have any idea how to trouble shoot this issue. I have upgraded to the latest version of instance-selector.

Any insight you can provide would be very much appreciated.

pip freeze for non working django 3 version, if changed to django 2 version it works as intended// appnope==0.1.0 asgiref==3.2.3 backcall==0.1.0 beautifulsoup4==4.6.0 certifi==2019.11.28 chardet==3.0.4 decorator==4.4.2 defusedxml==0.6.0 Django==3.0.4 django-allauth==0.41.0 django-debug-toolbar==2.2 django-extensions==2.2.8 django-invitations==1.9.3 django-mailjet==0.3.1 django-modelcluster==5.0.1 django-taggit==1.2.0 django-treebeard==4.3.1 djangorestframework==3.11.0 dnspython==1.16.0 draftjs-exporter==2.1.7 html5lib==1.0.1 idna==2.9 ipython==7.13.0 ipython-genutils==0.2.0 jedi==0.16.0 l18n==2018.5 mailjet-rest==1.3.3 oauthlib==3.1.0 parso==0.6.2 pexpect==4.8.0 pickleshare==0.7.5 Pillow==6.2.2 prompt-toolkit==3.0.3 protobuf==3.6.1 psycopg2==2.8.4 ptyprocess==0.6.0 Pygments==2.5.2 python3-openid==3.1.0 pytz==2019.3 PyYAML==5.3 requests==2.23.0 requests-oauthlib==1.3.0 six==1.14.0 sqlparse==0.3.0 traitlets==4.3.3 Unidecode==1.1.1 urllib3==1.25.8 wagtail==2.8 wagtail-instance-selector==1.2.1 wcwidth==0.1.8 webencodings==0.5.1 Willow==1.3

markfinger commented 4 years ago

This has only been tested against Django 1+2, so I'll need to do a pass and check compatibility with 3.

Redhaus commented 4 years ago

Thanks for the update. I looked through the repository, and I did not see any backward-incompatible issues between 2.2 and 3 that were relevant to the project. I have never done a migration between 2.2 and 3 so I am not sure where to begin to look. If you have any rough ideas on areas or files I should focus on, I would be happy to try to find what is causing the hangup.

Thanks again

I attached a screenshot for your reference of how it is not loading the UI in django 3

Screenshot 2020-03-25 21 38 35
Redhaus commented 4 years ago

This is how it loads in Django 2.2

Screenshot 2020-03-25 21 48 46
markfinger commented 4 years ago

Thanks for the screenshots.

If you'd like to dig in a bit, my suggestion would be to open the network panel in your browser's devtools and look at what the browser is loading when as it opens the modal. My best guesses would be that:

markfinger commented 4 years ago

It'd be great if you could find the time to poke around, but no worries either way. I'll try to find an hour or two some time this week to look into rigging up something to test Django 3 compat.

Redhaus commented 4 years ago

Awesome thank you for the direction! That helps a lot. I will do what you said and see if I can figure out where the issue is coming from.

Quadric commented 4 years ago

Hey... i have the same issue... the problem is about X-Frame-Options which in Django 3 is by default set to Deny...

It's not a good idea to change this default behavior for all requests https://docs.djangoproject.com/en/3.0/ref/clickjacking/#how-to-use-it

but instead it is possible to set apropriate header: like "SAMEORIGIN" for this special request using deorators: https://docs.djangoproject.com/en/3.0/ref/clickjacking/#setting-x-frame-options-per-view

Could be alright to set this decorator SAMEORIGIN for instance_selector view in this app?

markfinger commented 4 years ago

Could somebody try the above commit/PR in their local dev environment to see if the fix works with Django 3?

Quadric commented 4 years ago

I have to apologize because I didn't fully understand the problem. This MR wont work The real problem is not in your view but in wagtail view which you try to load into iframe. As is understand you load "standard" instances list from wagtail and then in JS you parse body response and build your own "instance list".

So fixing your view with "x-frame" decorators wont help.

How to solve this?

My only idea is to "extend" wagtail view responsible for listing instances (which you try to load into iframe) and set decorator on to that view.

What do you think?

Quadric commented 4 years ago

i guess this is in selectors.py line which gets url for instance list

    def get_instance_selector_url(self):
        index_url = self.model_admin.url_helper.index_url
        return index_url

it uses a url_helper with index_url and it contains a dedicated IndexView for ModelAdmin

markfinger commented 4 years ago

Ah, that does seem a bit more complicated. The list view's going to be broken, but also the create view as well 🤔

A couple of workarounds:

Use a mixin with the ModelAdmin that changes the X-FRAME header for all the views. This would be fine for models defined in a project, but it'll fall apart once we start touching Wagtail's builtins (User, etc).

Monkeypatch the ModelAdmin's views at runtime. This would solve built-ins (User, etc), but it's adding a bit of opaque magic that feels like it's going to be both fragile and annoying for edge-cases.

Use front-end requests to circumvent the iframe restrictions. As in use the main session to perform an ajax GET request on the list view and then embed the content. I think we could do this if it was a single page being loaded, but we'd need to handle every embedded link so it's going to end up complicated and with a lot of caveats.

markfinger commented 4 years ago

The ticket on Django where they change X-FRAME default: https://code.djangoproject.com/ticket/30426.

markfinger commented 4 years ago

If anyone's looking for a temporary workaround, you should be able to add the following to your settings

X_FRAME_OPTIONS = 'SAMEORIGIN'

This will change the iframe security flag back to the default in Django 1.x and 2.x.

markfinger commented 4 years ago

I've taken a quick try at a middleware approach. I don't think there's a good approach that doesn't involve circumventing most of the security offered by the X-Frame-Options default.

Besides requiring projects to set X_FRAME_OPTIONS = 'SAMEORIGIN', the only workaround is to try monkeypatching the views associated with a modeladmin. I think this might be possible for the common cases, but I'm a bit apprehensive about bespoke functional views like those used for wagtail's User admin.

markfinger commented 4 years ago

I haven't found a great solution for this that doesn't come with either security holes or half-broken code. The least-worst solution seems to be reverting X_FRAME_OPTIONS back to the default in Django 1.x & 2.x.

While I don't have any concrete plans at the moment, I'm mindful that we'll still need a solution for future projects. If/when there's an alternative that doesn't require iframes, I'll update this project and suggest using it as an alternative.

hemanthkumarr007 commented 1 year ago

image facing same issue everything is stored in same location i.e., image, title ,song..... but only the song is not playing