733520 - django forms aren't escaped on bedrock-dev

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

Description

[James Long (:jlongster)]

This is a little strange, but django forms aren't being escaped on the bedrock-dev site:

https://www-dev.allizom.org/en-US/apps/

It works fine locally. Someone pointed me to the monkeypatches at funfactory runs:

https://github.com/mozilla/funfactory/blob/master/funfactory/monkeypatches.py

The safe_django_forms.patch() is the thing that should be happening. Can you check the logs to make sure that the string "Note: funfactory monkey patches executed in ..." is being logged so see if the patches are being applied?

Comment 1

[Jake Maul [:jakem]]

I'm not sure where this would be logged... any ideas? I don't see anything in the error_log for www-dev.allizom.org that looks like django-ish... mostly just file-does-not-exist and various PHP warnings/errors.

I do see that file in ./vendor/src/funfactory/funfactory/monkeypatches.py... so it does at least exist on the system.

Comment 3

[Brandon Burton [:solarce]]

I'll try to get this figured out on Monday

Comment 4

[James Long (:jlongster)]

I've temporarily forced the forms to be escaped with the `safe` filter, but it's a little concerning that the monkeypatch wasn't working. I wonder if there are other patches that aren't being applied.

Once you get to work on this, let me know and I can come up with a test case.

Comment 5

[Fred Wenzel [:wenzel]]

As I understand it, it's not certain that that monkeypatch is actually not being applied, there could be another way in which, perhaps, Jinja2 isn't working the way it should.

Post-release, if it helps, we could also give James access to the dev server to try and poke around a django shell on the actual server.

Comment 6

[Corey Shields [:cshields]]

(In reply to Fred Wenzel [:wenzel] from comment #5)
> Post-release, if it helps, we could also give James access to the dev server
> to try and poke around a django shell on the actual server.

Good idea, he should have already been there.  I just added him to the user list, should make its way to the webheads within the next 20-40 mins.

Comment 7

[James Long (:jlongster)]

Thanks! I'll look around after tomorrow's push.

Comment 8

[James Long (:jlongster)]

Ok, the monkey patches are definitely not being applied. I can't believe I didn't notice this before, but we're getting CSRF errors on the forms, and the CSRF library is a monkey patch. We need to fix this today so QA can test the forms for tomorrows push.

Which server do I ssh to?

Comment 9

[Brandon Burton [:solarce]]

Either of bedrock[1-2].dev.seamicro.phx1.mozilla.com will be serving the dev site

If you do something like the following curl, you can test one server directly and watch logs

curl -H "Host: www.mozilla.org" -v bedrock1.dev.seamicro.phx1.mozilla.com:81/

:81 serves the SSL site, but SSL is terminated on the LB, hence the port number trick, but not HTTPS in the url

Comment 10

[Brandon Burton [:solarce]]

Were you able to find anything out on this? Do you require additional help from me/webops?

Comment 11

[Brandon Burton [:solarce]]

Let us know if you need additional assistance from webops

Comment 12

[Fred Wenzel [:wenzel]]

Yeah AFAIK the issue is not resolved yet. I'm assigning this to James, he should work on a django shell on -dev to find out where what's missing here.

Comment 13

[James Long (:jlongster)]

(In reply to Fred Wenzel [:wenzel] from comment #12)
> Yeah AFAIK the issue is not resolved yet. I'm assigning this to James, he
> should work on a django shell on -dev to find out where what's missing here.

I did do that, and I don't see anything out of the ordinary. Without the power to add a "import pdb; pdb.set_trace()" and step through the server, I can't figure out anything.

Could IT possibly do that? Add a trace at the top of manage.py and step through to see if the monkeypatch is being applied? I'm kinda stumped as to what else to do.

Comment 14

[Fred Wenzel [:wenzel]]

Can we give James root on that box for a period of time?

Comment 15

[Fred Wenzel [:wenzel]]

peterbe determined that the monkeypatches are not being run from within the wsgi interface. James, looks like this is next on your plate to put those monkeypatches into urls.py :)

Comment 16

[James Long (:jlongster)]

That has been fixed by updating playdoh and incorporating the patches myself. Finally!

Comment 17

[Fred Wenzel [:wenzel]]

Woot! Did you remove the occurrences of |safe that you had to add previously because this was broken?

Comment 18

[James Long (:jlongster)]

Nope, but I can do that now too.