Why does the session cookie work when serving from a domain but not when using an IP?

by

This is a “bug” in Chrome, not a problem with your application. (It may also affect other browsers as well if they change their policies.)

RFC 2109, which describes how cookies are handled, seems to indicate that cookie domains must be an FQDN with a TLD (.com, .net, etc.) or be an exact match IP address. The original Netscape cookie spec does not mention IP addresses at all.

The Chrome developers have decided to be more strict than other browsers about what values they accept for cookie domains. While at one point they corrected a bug that prevented cookies on IP addresses, they have apparently backpedaled since then and don’t allow cookies on non-FQDN domains (including localhost) or IP addresses. They have stated they will not fix this, as they do not consider it a bug.

The reason “normal” cookies are working but the session cookie is not is that you are not setting a domain for the “normal” cookies (it’s an optional parameter), but Flask automatically sets the domain for the session cookie to the SERVER_NAME. Chrome (and others) accept cookies without domains and auto-set them to the domain of the response, hence the observed difference in behavior. You can observer normal cookies failing if you set the domain to the IP address.

During development, you can get around this by running the app on localhost rather than letting it default to 127.0.0.1. Flask has a workaround that won’t send the domain for the session cookie if the server name is localhost. app.run('localhost')

In production, there aren’t any real solutions. You could serve this on a domain rather than an IP, which would solve it but might not be possible in your environment. You could mandate that all your clients use something besides Chrome, which isn’t practical. Or you could provide a different session interface to Flask that does the same workaround for IPs that it already uses for localhost, although this is probably insecure in some way.

Chrome does not allow cookies with IPs for the domain, and there is no practical workaround.

More Related Contents:

  1. Why not generate the secret key every time Flask starts?
  2. Scrapy – how to manage cookies/sessions
  3. Is there an easy way to make sessions timeout in flask?
  4. How to expire session due to inactivity in Django?
  5. secret key not set in flask session, using the Flask-Session extension
  6. How to return a dict as a JSON response from a Flask view?
  7. How to get POSTed JSON in Flask?
  8. Flask raises TemplateNotFound error even though template file exists
  9. Reference template variable within Jinja expression
  10. Is the server bundled with Flask safe to use in production?
  11. How many concurrent requests does a single Flask process receive?
  12. Handle Flask requests concurrently with threaded=True
  13. Make a POST request while redirecting in flask
  14. Saving upload in Flask only saves to project root
  15. redirect while passing arguments
  16. What is the purpose of Flask’s context stacks?
  17. error: [Errno 10053]
  18. Error when loading cookies into a Python request session
  19. Where should I place the secret key in Flask?
  20. Flask and uWSGI – unable to load app 0 (mountpoint=”) (callable not found or import error)
  21. RuntimeError: working outside of application context
  22. Method Not Allowed flask error 405
  23. SQLAlchemy: engine, connection and session difference
  24. How to save requests (python) cookies to a file?
  25. CSS Problems with Flask Web App
  26. Python Flask, how to set content type
  27. how to get access to error message from abort command when using custom error handler
  28. Gunicorn can’t find app when name changed from “application”
  29. ImportError: cannot import name ‘Markup’ from ‘jinja2’
  30. gcloud app deploy : This deployment has too many files

Leave a Comment