I have different endpoints when i run Django in apache compare to when I run it in the terminal.
Can it be some configuration in apache?
I belive it can be this ?
Apache 2 conf
ProxyPass "/ws/" "ws://127.0.0.1:8000/"
What does this mean; "/ws/"?
Apache to work:
ws_urlpatterns = [path('some_url/', Andring.as_asgi()), ]
Run in terminal:
ws_urlpatterns = [path('ws/some_url/', Andring.as_asgi()), ]
In JS:
const socket = new WebSocket("ws://" + window.location.host + "/ws/some_url/");
Related
So im trying to deploy a django app with nginx and uwsgi , ngnix is running well and the django app is working well with manage.py runserver , but when i try to deploy it with uwsgi it said Internal Server Error , and when i check my uwsgi logs that what i get (No module named django)
the virtualenv python version is 3.6.9 ,i'dont know if this error is caused because of imcompatibilty with python version of virtual environement and the Uwsgi one or just because i missed somethings , my uwsgi specs are
this is my uwsgi ini file :
[uwsgi]
vhost = true
plugins = python
socket = /tmp/mainsock
master = true
enable-threads = true
processes = 4
wsgi-file = /var/www/PTapp-launch/ptapp/wsgi.py
virtualenv = /var/www/venv/site
chdir = /var/www/PTapp-launch
touch-reload = /var/www/PTapp-launch/reload
env = DJANGO_ENV=production
env = DATABASE_NAME=personal_trainer
env = DATABASE_USER=postgres
env = DATABASE_PASSWORD=********
env = DATABASE_HOST=localhost
env = DATABASE_PORT=5432
env = ALLOWED_HOSTS=141.***.***.***
i have finally found the problem , when i was running manage.py runserver i had to use sudo , but when i didnt it was throwing the same error , (no module named Django) , so what i did its i uninstall all requirements and then use super user to create new virtual environnement and link it in uwsgi.ini, i also restart both of nginx and uwsgi, so everything work fine now ...
I deployed my Django project on Heroku with gunicorn. It's basically only the api (no templates).
When I deploy heroku and access <heroku url>/api/login for example in the browser
and post login data already in json format, it always returns
"detail": "Unsupported media type \"application/x-www-form-urlencoded\" in request."
But when I do the same on localhost, the user gets authenticated and I receive a response with user data...
post data example for login:
{ "email": "ana#test.com", "password": "ana1234567890" }
The parser_classes = [JSONParser] is added on every view where I don't have images or files (there I am using FileUploadParser).
I deployed on Heroku with gunicorn, because on localhost I permanently received "Unauthorized" from backend ( Permission Class is "isAuthenticated" for most of my views). After some research I figured out that probably the authorization header is not sent (here the APACHE WSGIPassAuthorization On would be a solution) but I don't have an apache server running and I don't want no webserver running on my machine.
I thought if I would deploy it on heroku with gunicorn, I could continue with the development without the "Unautorized" header but instead I run in other errors, like "detail": "Unsupported media type \"application/x-www-form-urlencoded\" in request." .. or the database connection is refused.
In my frontend I am sending the following header
// Headers
const token_config = {
headers: {
'content-type': 'application/json',
accept: 'application/json',
'Authorization': 'Bearer ${token}',
//withCredentials : true,
},
};
And the frontend is of course also receiving the "Wrong mediatype Error" .
I would be so greatfull if anybody could provide an detailed "howTo" for Django DRF + postgres on Heroku... I've wen't through lots of howtos, but none of them provides a fitting solution for this..
My main questions now are...
What does settings.py need so that the backend works on heroku just as fine as on localhost?
Do I really need to start the heroku postgres database manually with
heroku pg:psql postgresql-shaped-60432 --app every time after deployment? - Because If I don't, the herocu log shows:
2020-09-09T11:11:15.028985+00:00 app[web.1]: connection = Database.connect(**conn_params)
2020-09-09T11:11:15.028985+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/psycopg2/__init__.py", line 126, in connect
2020-09-09T11:11:15.028986+00:00 app[web.1]: conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
2020-09-09T11:11:15.028986+00:00 app[web.1]: django.db.utils.OperationalError: could not connect to server: Connection refused
2020-09-09T11:11:15.028987+00:00 app[web.1]: Is the server running on host "localhost" (127.0.0.1) and accepting
2020-09-09T11:11:15.028987+00:00 app[web.1]: TCP/IP connections on port 5432?
With this error + accessing the /api/login for example, I get an HTTP status of 503 or 500...
My requirements.txt:
Django==3.1.1
django-allauth==0.42.0
django-cors-headers==3.5.0
django-environ==0.4.5
django-rest-auth==0.9.5
django-sslserver==0.20
djangorestframework==3.11.1
djangorestframework-simplejwt==4.1.3
gunicorn==20.0.4
image==1.5.27
importlib-metadata==1.7.0
oauthlib==3.1.0
Pillow==7.2.0
psycopg2-binary==2.8.2
PyJWT==1.7.1
Thanks in advance and best regards!
Ok I fixed it!
I basically had to add all the settings.py stuff:
import django_heroku
import dj_database_url
ALLOWED_HOSTS = ['*']
DATABASES = {'default': dj_database_url.config(default='URI from Heroku-color- postgres database')}
# ALL THE STATIC PATHS
MEDIA_ROOT = os.path.join(BASE_DIR,'media')
MEDIA_URL = '/media/'
#location where django collect all static files
STATIC_ROOT = os.path.join(BASE_DIR,'static')# location where you will store your static files
STATICFILES_DIRS = [os.path.join(BASE_DIR,'walkAdog/static')]
STATIC_URL = '/static/'
# for deployement on heroku
django_heroku.settings(locals())
AT THIS POINT the origin error “detail”: “Unsupported media type \”application/x-www-form-urlencoded\“ in request.” did not appear anymore
.. But the next error occured: No module named 'django_heroku'...
So I figured out, that django-heroku was not installed correctly, since the pipenv install psycopg crashed - worked for me as I did installed pipenv install psycopg2==2.7.7 and then django whitenoise dj-database-url psycopg2
instead, the database was "empty" - quite predictable..
So I did makemigrations on localhost
then commit the project/migrations folder (and the rest)
and ran heroku run python manage.py migrate
-> everything working fine now!!
Basically, I just had to follow the steps from https://medium.com/#hdsingh13/deploying-django-app-on-heroku-with-postgres-as-backend-b2f3194e8a43 .. I just kinda didn't understand the neccessarity of all the stuff..
I am testing my Flask app on AWS EC2 instance (Ubuntu).
Main app:
from sonip.api.factory import create_app
app = create_app()
def main():
app.run(debug=True, threaded=True)
if __name__ == "__main__":
main()
The actual set up of the Flask app is done in a factory including registering blueprint, etc.
def create_app():
app = Flask(__name__)
app.config['SERVER_NAME'] = settings.FLASK_SERVER_NAME
app.config['SWAGGER_UI_DOC_EXPANSION'] = settings.RESTPLUS_SWAGGER_UI_DOC_EXPANSION
app.config['RESTPLUS_VALIDATE'] = settings.RESTPLUS_VALIDATE
app.config['RESTPLUS_MASK_SWAGGER'] = settings.RESTPLUS_MASK_SWAGGER
app.config['ERROR_404_HELP'] = settings.RESTPLUS_ERROR_404_HELP
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False
app.config["SQLALCHEMY_DATABASE_URI"] = "postgresql://{}:{}#{}:{}/{}".format(
settings.DB_USER,
settings.DB_PASS,
settings.DB_HOST,
settings.DB_PORT,
settings.DB_NAME)
db.init_app(app)
blueprint = Blueprint('api', __name__, url_prefix='/api')
app.register_blueprint(blueprint)
return app
When I run python application.py and use curl -X GET http://localhost:5000/api, it returns the correct Swagger page. However, if I tried to run the app by specifying host=0.0.0.0 for external traffic, I got 404 for the same request.
(env) ubuntu#ip-172-31-18-136:~/aae$ python application.py
* Serving Flask app "sonip.api.factory" (lazy loading)
* Environment: production
WARNING: Do not use the development server in a production environment.
Use a production WSGI server instead.
* Debug mode: on
* Running on http://localhost:5000/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 948-062-124
127.0.0.1 - - [16/May/2018 18:07:24] "GET /api/ HTTP/1.1" 200 -
♥(env) ubuntu#ip-172-31-18-136:~/aae$ vi application.py
(env) ubuntu#ip-172-31-18-136:~/aae$ python application.py
* Serving Flask app "sonip.api.factory" (lazy loading)
* Environment: production
WARNING: Do not use the development server in a production environment.
Use a production WSGI server instead.
* Debug mode: on
* Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 948-062-124
165.225.34.185 - - [16/May/2018 18:08:28] "GET /api/ HTTP/1.1" 404 -
Port 5000 is open to allow all inbound traffic in the security group. I tried a vanilla Flask app with just a few line of code, it worked just fine.
app = Flask(__name__)
if __name__ == '__main__':
app.run(debug=True, port=8080, host='0.0.0.0')
This at least means 5000 is fine. Could it be the Blueprint or Swagger?
Setting SERVER_NAME and changing the host/port to something different in app.run() used to be a recipe for problems. At best, it's under-documented.
Try changing settings.FLASK_SERVER_NAME to 0.0.0.0:5000. Or if your app wants to be using cookies, try the trick of using something.dev:5000 and adding an entry for something.dev to your local /etc/hosts.
I have deployed my django web application on my institute server using apache and mod_wsgi and I am using django-allauth google authentication. My institute network uses few proxy servers to interact with the Internet.
Google authentication works fine while I am running app on localhost, but as soon as I migrate the app to https_://fusion.*******.ac.in, google authentication shows following
Error image
callback uri: https_://fusion.*******.ac.in/accounts/google/login/callback/
Please help me with this problem.
Add following lines in your wsgi file.
import os
http_proxy = "host:port"
https_proxy = "host:port"
ftp_proxy = "host:port"
proxyDict = {
"http" : http_proxy,
"https" : https_proxy,
"ftp" : ftp_proxy
}
os.environ["PROXIES"] = proxyDict
I have a problem with django channels.
My Django app was running perfectly with WSGI for HTTP requests.
I tried to migrate to channels in order to allow websocket requests, and it turns out that after installing channels and running ASGI (daphne) and a worker, the server answers error 503 and the browser displays error 504 (time out) for the http requests that were previously working (admin page for example).
I read all the tutorial I could find and I do not see what the problem can be. Moreover, if I run with "runserver", it works fine.
I have an Nginx in front of the app (on a separate server), working as proxy and loadbalancer.
I use Django 1.9.5 with asgi-redis>=0.10.0, channels>=0.17.0 and daphne>=0.15.0. The wsgi.py and asgi.py files are in the same folder. Redis is working.
The command I was previously using with WSGI (and which still works if I switch back to it) is:
uwsgi --http :8000 --master --enable-threads --module Cats.wsgi
The command that works using runserver is:
python manage.py runserver 0.0.0.0:8000
The commands that fail for the requests that work with the 2 other commands are:
daphne -b 0.0.0.0 -p 8000 Cats.asgi:channel_layer
python manage.py runworker
Other info:
I added 'channels' in the installed apps (in settings.py)
other settings.py relevant info
CHANNEL_LAYERS = {
"default": {
"BACKEND": "asgi_redis.RedisChannelLayer",
"ROUTING": "Cats.routing.app_routing",
"CONFIG": {
"hosts": [(os.environ['REDIS_HOST'], 6379)],
},
},
}
Cats/routing.py
from channels.routing import route, include
from main.routing import routing as main_routing
app_routing = [
include(main_routing, path=r"^/ws/main"),
]
main/routing.py
from channels.routing import route, include
http_routing = [
]
stream_routing = [
route('websocket.receive', 'main.consumers.ws_echo'), #just for test once it will work
]
routing = [
include(stream_routing),
include(http_routing),
]
main/consumers.py
def ws_echo(message):
message.reply_channel.send({
'text': message.content['text'],
})
#this consumer is just for test once it will work
Any idea what could be wrong? All help much appreciated! Ty
EDIT:
I tried a new thing:
python manage.py runserver 0.0.0.0:8000 --noworker
python manage.py runworker
And this does not work, while python manage.py runserver 0.0.0.0:8000 was working...
Any idea that could help?
channels will use default views for un-routed requests.
assuming you use the javascripts right, I suggest you use only your default Cats/routing.py file as following:
from channels.routing import route
from main.consumers import *
app_routing = [
route('websocket.connect', ws_echo, path="/ws/main")
]
or with reverse to help with your path
from django.urls import reverse
from channels.routing import route
from main.consumers import *
app_routing = [
route('websocket.connect', ws_echo, path=reverse('main view name'))
]
I think also your consumer should be changed. when browser connects using websockets the server should first handle adding message reply channel. something like:
def ws_echo(message):
Group("notifications").add(message.reply_channel)
Group("notifications").send({
"text": json.dumps({'testkey':'testvalue'})
})
the send function should probably be called up on different event and the "notifications" Group should probably changed to have a channel dedicated to the user. something like
from channels.auth import channel_session_user_from_http
#channel_session_user_from_http
def ws_echo(message):
Group("notify-private-%s" % message.user.id).add(message.reply_channel)
Group("notify-private-%s" % message.user.id).send({
"text": json.dumps({'testkey':'testvalue'})
})
If you're using heroku or dokku make sure you've properly set the "scale" to include the worker process. By default they will only run the web instance and not the worker!
For heroku
heroku ps:scale web=1:free worker=1:free
For dokku create a file named DOKKU_SCALE and add in:
web=1
worker=1
See:
http://blog.codelv.com/2017/10/timouts-django-channels-on-dokku.html
https://blog.heroku.com/in_deep_with_django_channels_the_future_of_real_time_apps_in_django