Guestbook on OpenFaas/Python

[juliogomez]

Guestbook implementation on OpenFaaS+Python.

[nerdguru]

As we discussed offline, the CORS return headers aren't quite right yet for browser consumption. It appears as though the OpenFaaS Python template isn't passing in OPTIONS requests to your function code, something I ran into for the Node template as well.

When you do a curl -v on a POST you see the right headers being set:

$ curl -X POST --header "Content-Type:application/json" -d '{"text":"Hello Again"}'  http://10.10.20.202:31112/function/create -v
*   Trying 10.10.20.202...
* Connected to 10.10.20.202 (10.10.20.202) port 31112 (#0)
> POST /function/create HTTP/1.1
> Host: 10.10.20.202:31112
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type:application/json
> Content-Length: 22
> 
* upload completely sent off: 22 out of 22 bytes
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Content-Length: 87
< Content-Type: application/json
< Date: Thu, 04 Oct 2018 02:43:25 GMT
< Server: Werkzeug/0.14.1 Python/2.7.15
< X-Call-Id: 2712f891-b735-43b3-a45a-fbef31ca8e59
< X-Start-Time: 1538621000110868432
< 
* Connection #0 to host 10.10.20.202 left intact
{'text': u'Hello Again', '_id': '5bb57e4d39983c000a57a5d3', 'updatedAt': 1538621005136}

In particular, Access-Control-Allow-Origin is getting set by your code as expected.

But when you do the same on OPTIONS, the headers aren't getting set, likely because something else is handling that verb:

$ curl -X OPTIONS --header "Content-Type:application/json" -d '{"text":"Hello Again"}'  http://10.10.20.202:31112/function/create -v
*   Trying 10.10.20.202...
* Connected to 10.10.20.202 (10.10.20.202) port 31112 (#0)
> OPTIONS /function/create HTTP/1.1
> Host: 10.10.20.202:31112
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type:application/json
> Content-Length: 22
> 
* upload completely sent off: 22 out of 22 bytes
< HTTP/1.1 200 OK
< Allow: HEAD, GET, POST, OPTIONS
< Content-Length: 0
< Content-Type: text/html; charset=utf-8
< Date: Thu, 04 Oct 2018 02:40:23 GMT
< Server: Werkzeug/0.14.1 Python/2.7.15
< X-Call-Id: f978ee86-26d5-401a-b1eb-5a234d5b9156
< X-Start-Time: 1538620818398823778
< 
* Connection #0 to host 10.10.20.202 left intact

Not only is Access-Control-Allow-Origin not getting set, but your code is returning a different Allow set of verbs so clearly your code isn't getting executed.

I tried going into the template index.py and changed:

@app.route("/", defaults={"path": ""}, methods=["POST", "GET"])
@app.route("/<path:path>", methods=["POST", "GET"])

to

@app.route("/", defaults={"path": ""}, methods=["POST", "GET", "OPTIONS"])
@app.route("/<path:path>", methods=["POST", "GET", "OPTIONS"])

but that didn't work, so there's some deeper Flask investigating to do here. I'm happy to do that if you'd like, but I won't have time until Monday at the earliest.

[nerdguru]

OK, turns out I'm a total idiot.

In my haste when checking this before, what I failed to realize is that, when trying to open up the OPTIONS verb to your code by altering the OpenFaaS template, I altered the wrong version of the template. I changed the python3-flask template when your create.template I used to create a create.yml clearly states it is using python27-flask.

The good news is, by simply adding the OPTIONS verb to that template everything worked perfectly, so I'd recommend the following steps (including another minor bug I found):

1) Add the python27-flask template code to your codebase, much like I had to do for Node.js 2) Add the OPTIONS verb to lines 9 and 10 of this new local copy 3) File a PR back with the https://github.com/openfaas-incubator/python-flask-template 4) Change line 6 of your list.template, which should read "list", not "create" 5) Resubmit this PR and keep an eye out for your OpenFaaS PR to be accepted, in which case you can remove the template code from your source tree.

[juliogomez]

Many thanks for your guidance and clarification, Pete. I gave it a try and now everything works great!