Possible SSL or Certification issue on Development Server?

[sid9553]

Hi jpic,

First off, thanks for your ongoing support and development of this highly useful app. I have encountered an error when using this app on my development server. The app works perfectly locally, however on the devserver the 'filter' function doesn't work. On doing some tests and prints, the app appears to be being blocked from sending out the request, and is returning 'None' to the filtered field, which results in no filtering. We have a had a look at the actual urls and data being sent out, and as said before on the devserver it is none. Here is a copy of the url on both servers (local server first) on clicking the filtered dropdown.

http://127.0.0.1:8000/stepoptionautocomplete/?forward=%7B%22step%22%3A%222%22%7D

https://webdev.hieta.biz/hieta/stepoptionautocomplete/

The devserver appears to not run the forward.js file, and so far I've been theorizing that something has been blocking it. We are running Python2.7 on Apache 2.4.7 and had an insecurePlatformWarning but updated the urllib3 to counter this.

I am wondering if you had encountered something like this before and had any ideas on how to fix it. All suggestions are appreciated.

Regards Ahmad

[jpic]

Pleased to meet you Ahmad, but I don't understand how to reproduce this bug, and none of the URLs respond for me.

I suggest you use a Python debugger to figure what's going on exactly, what's the difference in the context of both cases, and if possible make a pull request with the code you've needed to change to make it work for you which will make it even better to understand what we need to fix ;)

[gagarski]

Hi Ahmad.

It seems like there is some client-side issue on your dev server. First of all, compare contents of JS files related to DAL (especially autocomplete_light/select2.js and autocomplete_light/forward.js) between your localhost and dev server using your browser dev tools. If they differ, please ensure that you use the same DAL version. Or maybe you just have to run ./manage.py collectstatic to update static files.

[jpic]

Perhaps this can help: too: http://blog.yourlabs.org/post/30382323418/surviving-djangocontribstaticfiles-or-how-to ​

[sid9553]

Thanks for your suggestions. For now I've written my own autocomplete fields (not quite as nice as yours), until I figure why it isn't running on dev. Collectstatic has been run and all static files are identical, as mentioned previously and after speaking with a colleague, we believe it's a security thing.

[jpic]

Ohhh, perhaps you have a WAF that blocks the forward request because it's a json encoded value !

It believes this JSON url encoded string is a shellcode or something : %7B%22step%22%3A%222%22%7D Lol, silly WAF :poodle:

Perhaps you could patch DAL to support POST-ing this data ? It shouldn't be hard, i think it's just an option in select2.

[gagarski]

@sid9553 Do you see these request URLS in server logs or in browser dev console?

http://127.0.0.1:8000/stepoptionautocomplete/?forward=%7B%22step%22%3A%222%22%7D

https://webdev.hieta.biz/hieta/stepoptionautocomplete/

[sid9553]

gagarski, those are the urls that show up in the browser dev console. jpic, I believe your theory is highly likely, I'll have a look at select2.

[sid9553]

Hi jpic,

I haven't found the option in select2 that you are talking about. I have tried to see which portion of select2 the app is running through, and it doesn't seem to be running through select2, I'm only getting prints from dal views (dispatch function), dal widgets, and forward.js. Could you point me in the right direction?

Regards

[gagarski]

@sid9553 Could you look carefully at network tab of your browser dev console? Is hieta/stepoptionautocomplete/ only request sent from your browser to server (or you get some redirects from server or smth)? If so, this is likely client-side issue not related to server configuration and WAF and we have to debug DAL JS.

[gagarski]

@jpic Please correct me if I've understood your thoughts about WAF wrongly.

[jpic]

If the requests URL in the server logs correspond exactly to the URL in the browser inspector Network tab, then it's not a WAF issue.