1

The flask session variable is not accessible during program execution as deployed. I am using ubuntu 18.04 uwsgi 2.0.19.1 and python 3.7.2 to publish a flask app on GCP Compute Engine. Everything looks good on www.minusthemiddleman.com except for when I try to go to page two of my search. Then I get a message: Internal Server Error The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application. It’s interesting because the debugging that I have done has shown that a specific variable that I store in session is not available. I’ve tried padding the code with more storage opportunities and also made session permanent and neither fix has resolved the issue. At first coding with more session writes seemed to work in the dev.ini. Then they failed when pushed out to the www. Going further, I tried to make session permanent to no lasting effect there either. I’ve done some additional reading and found a possible solution with Gunicorn. Does anyone have experience with switching from uwsgi to Gunicorn to solve this kind of problem or should I look to other solutions? Can uwsgi be used to help serve out a Flask App or is this just now done this way? Please share your experiences and Thanks ahead of time for your efforts.

tlmtransmogrify
  • 21
  • 3
  • I found an article written a while ago that compares some performance specifications. It's interesting and I thought I would share here. https://blog.kgriffs.com/2012/12/18/uwsgi-vs-gunicorn-vs-node-benchmarks.html The benchmark testing seems to indicate that uwsgi is ultimately faster and if I could get it to work then that may be the way to go based on speed alone. Thanks – tlmtransmogrify May 04 '21 at 13:43
  • There seems to be a SEO benefit to switching the website to ssl operation such as https. I will still use Nginx and some sort of public and private key pair in a seperate directory and reference by my nginx conf file. This may fix it and it's my best guess now. I have found no actual web references for whether or not this will fix the original error or if this is just a good process improvement in general. So I will push forward with it on the merits that it will be a process improvement with a chance of changing the environment that production is executed in. Maybe it will fix it. Thanks – tlmtransmogrify May 05 '21 at 15:07
  • Conversion to https operation seems to go well. Just need to incorporate the letsencrypt key pair into the nginx operation and it should be done. – tlmtransmogrify May 09 '21 at 16:50
  • It's interesting, I'm getting exactly the same error code. SSL: error:0909006C:PEM as a post on Stack overflow. After updating to crt and key Ngnix is not responding well to the changes and won't revert back to previous settings using the old er config file. It's almost working. One good point is that the ssl verifier that was mentioned states my .crt and .key file are not acceptable and that might be a good place to start from https://www.sslchecker.com/certdecoder as mentioned in thread https://stackoverflow.com/questions/63030755/error-error0909006cpem-routinesget-nameno-start-line-node. – tlmtransmogrify May 11 '21 at 17:54
  • I’ve found a new way to determine if the cert is valid on the ubuntu server from the command line. $ openssl x509 -text -noout -in /etc/letsencrypt/csr/somesslcertificate.crt This seems to validate that the certs are not working. Also nginx won’t revert back to working on http even when I change the configs back and double check my permissions and change them for ufw. I am considering uninstalling nginx and certbot and then reinstalling them. So just to recap, it worked for a moment but when I attempted to add https functions it failed and won’t reset to http operation. – tlmtransmogrify May 13 '21 at 11:31
  • I went ahead and toggled some things. The server, the firewall rules, stopped the app, and made sure no extra port 80s were open. Anydesk and google seem to burn two port 80 connections, but I got rid of the other three. I read somewhere that having them active can mess with nginx on start up. I have also created a public.key because ngnix keeps looking for it: $ nginx: [emerg] PEM_read_bio_X509_AUX("/etc/letsencrypt/keys/public.key") failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUSTED CERTIFICATE) nginx: configuration file /etc/nginx/nginx.conf test failed – tlmtransmogrify May 14 '21 at 11:02
  • Changes the header in public from -----BEGIN PUBLIC KEY----- to -----BEGIN TRUSTED CERTIFICATE----- seems to give a new error. Which is promising because that’s proof that this file is significant. Although I’m not sure why. If ngnix has the fullchain.pem and a private key already then I’m pretty sure that it can create the public from the fullchain like I did. I guess it’s just more convenient to have it on hand for distribution. – tlmtransmogrify May 14 '21 at 11:02
  • sudo nginx -t nginx: [emerg] PEM_read_bio_X509_AUX("/etc/letsencrypt/keys/public.key") failed (SSL: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag error:0D06C03A:asn1 encoding routines:asn1_d2i_ex_primitive:nested asn1 error error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:Field=serialNumber, Type=X509_CINF error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:Field=cert_info, Type=X509 error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib) nginx: configuration file /etc/nginx/nginx.conf test failed – tlmtransmogrify May 14 '21 at 11:02
  • I went ahead and purged nginx and reinstalled. Made a backup of the clean nginx copy this time. HTTP only shouldn’t matter in the regular sense. The regular sense being the use of form data for login and passwords between the html5 and the python code in Flask. This site doesn’t use form in that way. SEO will be affected directly of course. I found a thread that offered some promise towards a solution using gunicorn https://stackoverflow.com/questions/67533643/nginx-doesnt-switch-from-http-to-https. Unfortunately, there is no conclusive answer so that I may find a parallelism to this issue. – tlmtransmogrify May 15 '21 at 21:32

0 Answers0