Hi
I have been trying to resolve this issue for some time but I cannot get around it.
I was able to successfully deploy a Flask application and get into the Log-in page successfully. But when after submitting the log-in credentials I get a Bad Request error.
From the logs I can see that my login endpoint is executed with a GET request but not with the POST.
My feeling is that the issue might be around csrf tokens and maybe the way I set-up the environment variables, but I am not sure.
Do you think you can help narrowing down the problem? Have you seen the same or similar issue in the past?
As this looks like an issue specific to Flask, I recommend reaching out to a community that specializes in that area for assistance, or at least doing some online research about the error. That being said, here is a Stack Overflow thread I found that might help get you started: https://stackoverflow.com/questions/8552675/form-sending-error-flask.
Hi Mike
thanks for your prompt response. While I would agree this might be something specific to Flask app, the challenge I have is that I cannot get the relevant logs to investigate further the matter. As I mentioned at the beginning, it seems the endpoint is not even called, so the thread you mentioned is not applicable in this case.
It seems the issue might be related to csrf token, but so far I have not found a way to verify that and I was wondering if you have any suggestion
thanks
Just so I understand correctly, it sounds like the core problem here is that your Flask login page form submission is only making a GET call and not a POST call as well? Is that correct, or am I misunderstanding something?
Hi Mike
no the login as well as signup pages can make both GET and POST calls. The GET calls will render the page correctly but when submitting the login or signup form in the page then the error 400 occurs.
I was able to get more details about the message associated with the error and it seems that the CSRF session token is missing. At this stage I am not sure why this is happening in production and not in local environment.
If you have any hints you are more than welcome
Thanks
Unfortunately I am not very familiar with Flask, so your best bet is to do some further online research to see if anyone else has run into this issue. Here are a few threads I found that may help a bit:
Hi Mike
While searching for solutions to this problem I came across to this:
One of the suggested approach is to run gunicorn with multiple threads, so I tried the following command but it does not make any difference to my application:
gunicorn --threads 4 --workers 2 -b 0.0.0.0:5000 “src.app:create_main_and_celery_apps()”
I am not an expert with gunicorn commands, so I wouldn’t be the best person to answer these questions. I recommend appealing to the gunicorn docs and checking the service logs for any build/deploy errors, and making adjustments where necessary. It may also be of help to post your questions to a dedicated Python community for more tailored assistance.
Sorry I can’t be of more help here, but I just don’t have much of a background with Python.
Hi Mike
sorry for not being clear. The questions are more related to Render, let me explain:
For the first question I know the syntax is correct but I was wondering if there is anything that I should be aware of to make sure it is correctly managed when running that command under the Render infrastructure
For the second question as well, I was wondering if there is a way within the Render dashboard to check the application is running with multi-threads
Many thanks
Marco
There is nothing unique to Render about running gunicorn commands, or running gunicorn more broadly.
No, however if you were to ever upgrade the service to a paid instance type, it would enable the ability to use a built-in Shell where you could run commands against the server. Whether there was a command that would show you how many threads are running, you would have to look up, as it would not be anything Render-specific. A paid instance type would also enable the ability to scale the service with multiple instances. Lastly, another thought might be to add more application logging to note when new threads are spun up.
