I have the following configuration for flask:
app.config['SESSION_REFRESH_EACH_REQUEST'] = False
app.config['SESSION_PERMANENT'] = True
I understood that since 'SESSION_REFRESH_EACH_REQUEST' is False, it will not send set-cookie in the response when session is not modified.
In the after_request I check if session was modified:
#app.after_request
def add_header(response):
if session.modified == False:
print(response.headers)
return response
It indeed wasn't!
No matter what I do, even when I explicit set session.modified = False, flask response have a set-cookie header with the session ID.
I need flask to not send set-cookie in the response because I want to connect my website with cloudflare, caching every response. How can I do it?
To remove the behavior of sending set-cookies in http header, I modified the "should_set_cookie" function of session interface, right after you create you app instance:
from flask.sessions import SecureCookieSessionInterface, SessionMixin
class CustomSessionInterface(SecureCookieSessionInterface):
def should_set_cookie(self, app: "Flask", session: SessionMixin) -> bool:
if (session.modified == False and request.method == 'GET'):
return False
else:
return True
app.session_interface = CustomSessionInterface()
This made sure it will not set-cookies if the session wasn't modified and is a GET request.
This is helping me a lot in cloud caching!
Related
I am currently trying to do a fetch request when logged into the web app but i keep getting a .
87466804-e84d-413e-abd1-74dc56624149-ide.cs50.xyz/sell:1 Failed to load resource: the server responded with a status of 502 (Bad Gateway)
and then
sell:1 Access to fetch at 'http://87466804-e84d-413e-abd1-74dc56624149-ide.cs50.xyz/sell' from origin 'http://127.0.0.1:5000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
My Flask app looks like
#app.route("/sell", methods=["GET", "POST"])
#login_required
def sell():
ticker_symbols = helper_index.get_ticker_symbols(currently_owned_table)
#handles GET request
if request.method == "GET":
return render_template("sell.html", companies=ticker_symbols)
if request.method == "POST":
#handles submitted form
if "sell_form" in request.form:
#if form is submitted
return "thanks"
#handles fetch request
else:
the_request = request.get_json()
the_symbol = [the_request["symbol"]]
shares_available = helper_index.get_total_shares(the_symbol, currently_owned_table)
requested_shares = the_request["shares"]
print(requested_shares)
if int(requested_shares) <= shares_available[0]:
return "true"
else:
return "false"
I'm unsure how to fix this? and ideas appreciated
Flask-CORS does magic.
app.py:
app = Flask(__name__)
cors = CORS(app, resources={r"/*": {"origins": "*"}})
#app.route("/api/v1/users")
def list_users():
return "user example"
In my Flask API, I'm trying to get sessions to stay permanent, so that it will still be there even after browser closes. My front-end is written in React, and uses the Fetch API to make requests. However, after testing out what I have so far, it doesn't seem to work. My code (left out some irrelevant database stuff that works):
#bp.route('/login', methods=('POST',))
def login():
...
error=None
res = {}
db = get_db()
cursor = db.cursor(dictionary=True)
...
user = cursor.fetchone()
...
if error is None:
session.clear()
session.permanent = True
session['userID'] = user['id']
current_app.logger.debug(session['userID'])
res['actionSuccess']= True
else:
res['actionSuccess'] = False
res['error'] = error
return jsonify(res)
So far, I can tell that sessions is indeed storing the userID value. I then write another route to tell me if an userID value is stored in session, like so:
#bp.route('/init', methods=('GET',))
def init():
userID = session.get('userID')
if userID is None:
res = {"signedIn": False}
else:
res = {"signedIn": True, "username": userID}
return jsonify(res)
However, everytime I make the call to '/init', it returns False even though I previously signed in. I don't know why session isn't permanent here. Is it because I'm running the client locally on my machine? Do I need to allow cookies somewhere on my Chrome browser? I used Chrome to look into the cookies stored for the client, and no "sessions" was stored there. Do I have to something extra on the front-end to store the cookies/session, or do they store automatically? Am I misunderstanding the usage of Flask sessions?
Found out why sessions wasn't working after a lot of research! Flask sessions are essentially cookies, and I was using the Fetch API to perform CORS operations. Fetch() by default does not allow cookies to be received or sent, and must be configured in order to use Flask sessions.
On my React.js client, I did this by setting 'include' for 'credentials':
fetch(url, {
method: 'POST',
mode: 'cors',
body: JSON.stringify(loginObj),
credentials: 'include',
headers: {
'Content-Type': 'application/json'
}
})
.then(res => res.json())
...
Because of this configuration, the request isn't considered a "simple request", and the client will actually "preflight" the POST request with an OPTIONS request. This means that before my POST request is sent, a OPTIONS request testing to see if the server has the correct access will be sent to my Flask server first.
The preflight OPTIONS request will test to see if the response from the server has the correct headers containing "Access-Control-Allow-Origin", 'Access-Control-Allow-Credentials', and 'Access-Control-Allow-Headers'. If the test sent by the OPTIONS request fails, the actual POST request will not be sent and you'll get a Fetch error.
I then set the headers accordingly on my Flask server like so:
#bp.route('/login', methods=('POST','OPTIONS'))
def login():
if request.method == 'OPTIONS':
resp = Response()
resp.headers['Access-Control-Allow-Origin'] = clientUrl
resp.headers['Access-Control-Allow-Credentials'] = 'true'
resp.headers['Access-Control-Allow-Headers'] = "Content-Type"
return resp
else:
'''
use session for something
'''
res['actionSuccess'] = False
js = json.dumps(res)
resp = Response(js, status=200, mimetype='application/json')
resp.headers['Access-Control-Allow-Origin'] = clientUrl
resp.headers['Access-Control-Allow-Credentials'] = 'true'
resp.headers['Access-Control-Allow-Headers'] = "Content-Type"
return resp
Take note that 'Access-Control-Allow-Credentials' was set to 'true' as opposed to the Python boolean True, as the client will not recognize the Python boolean.
And with that, a Flask Session object should be stored in your cookies.
I'm trying to create a simple login test using Django and Selenium, but getting a 403 due to a CSRF failure. I'm expecting the middleware to add the cookie on the GET request and then parse it back out on the POST.
Here's what I've checked so far:
1. Is the cookie being set on the GET request to /accounts/login/?
Yes, the cookie is being set in the process_response method
2. Is the cookie available on the Selenium driver?
Yes
ipdb> self.selenium.get_cookies()
[{u'domain': u'localhost', u'name': u'csrftoken', u'value': u'DzNbEn9kZw0WZQ4OsRLouriFN5MOIQos', u'expiry': 1470691410, u'path': u'/', u'httpOnly': False, u'secure': True}]
3. Is the cookie found during the POST request?
No, this try/except from django.middleware.CsrfViewMiddleware.process_view fails:
source
try:
csrf_token = _sanitize_token(
request.COOKIES[settings.CSRF_COOKIE_NAME])
# Use same token next time
request.META['CSRF_COOKIE'] = csrf_token
except KeyError:
csrf_token = None
# Generate token and store it in the request, so it's
# available to the view.
request.META["CSRF_COOKIE"] = _get_new_csrf_key()
Code
class TestLogin(StaticLiveServerTestCase):
#classmethod
def setUpClass(cls):
cls.selenium = getattr(webdriver, settings.SELENIUM_WEBDRIVER)()
cls.selenium.maximize_window()
cls.selenium.implicitly_wait(5)
super(TestLogin, cls).setUpClass()
#classmethod
def tearDownClass(cls):
cls.selenium.quit()
super(TestLogin, cls).tearDownClass()
def test_login(self):
self.selenium.get('{}{}'.format(self.live_server_url, '/accounts/login/?next=/'))
assert "Django" in self.selenium.title
un_el = self.selenium.find_element_by_id('id_username').send_keys('the_un')
pw_el = self.selenium.find_element_by_id('id_password')
pw_el.send_keys('the_pw')
pw_el.send_keys(Keys.RETURN)
try:
WebDriverWait(self.selenium, 5).until(EC.title_contains("New Title"))
except TimeoutException as e:
msg = "Could not find 'New Title' in title. Current title: {}".format(self.selenium.title)
raise TimeoutException(msg)
finally:
self.selenium.quit()
Question
What can I try next to debug this?
Oldish question, but after getting stuck with this for a few hours the answer was simple.
From the docs:
If a browser connects initially via HTTP, which is the default for
most browsers, it is possible for existing cookies to be leaked. For
this reason, you should set your SESSION_COOKIE_SECURE and
CSRF_COOKIE_SECURE settings to True. This instructs the browser to
only send these cookies over HTTPS connections. Note that this will
mean that sessions will not work over HTTP, and the CSRF protection
will prevent any POST data being accepted over HTTP (which will be
fine if you are redirecting all HTTP traffic to HTTPS).
Like me, you are probably using django_extensions + Werkzeug for the majority of your work, and are by default running all of your local work over SSL.
If you're using unittest or Djangos version of it, I'd recommend that you modify these settings at test runtime, like so:
...
from django.conf import settings
class ProfilePagetest(LiveServerTestCase):
def setUp(self):
settings.CSRF_COOKIE_SECURE = False
settings.SESSION_COOKIE_SECURE = False
self.url = reverse('clientpage:profile')
self.username = 'name#names.com'
self.password = 'strange decisions...'
get_user_model().objects.create_user(self.username, self.username, self.password)
self.browser = webdriver.Firefox()
This should stop the CSRF validation issues.
I've used the UpdateCacheMiddleware and FetchFromCacheMiddleware MiddleWare to enable site-wide anonymous caching to varying levels of success.
The biggest problem is that the Middleware only caches an anonymous user's first request. Since a session_id cookie is set on that first response, subsequent requests by that anonymous user do not hit the cache as a result of the view level cache varying on Headers.
My webpages do not meaningfully vary among anonymous users and, in so far as they do vary, I can handle that via Ajax. As a result, I decided to try to subclass Django's caching Middleware to no longer vary on Header. Instead, it varies on Anonymous vs. LoggedIn Users. Because I am using the Auth backend, and that handler occurs before fetching from the cache, it seems to work.
class AnonymousUpdateCacheMiddleware(UpdateCacheMiddleware):
def process_response(self, request, response):
"""
Sets the cache, if needed.
We are overriding it in order to change the behavior of learn_cache_key().
"""
if not self._should_update_cache(request, response):
# We don't need to update the cache, just return.
return response
if not response.status_code == 200:
return response
timeout = get_max_age(response)
if timeout == None:
timeout = self.cache_timeout
elif timeout == 0:
# max-age was set to 0, don't bother caching.
return response
patch_response_headers(response, timeout)
if timeout:
######### HERE IS WHERE IT REALLY GOES DOWN #######
cache_key = self.learn_cache_key(request, response, self.cache_timeout, self.key_prefix, cache=self.cache)
if hasattr(response, 'render') and callable(response.render):
response.add_post_render_callback(
lambda r: self.cache.set(cache_key, r, timeout)
)
else:
self.cache.set(cache_key, response, timeout)
return response
def learn_cache_key(self, request, response, timeout, key_prefix, cache=None):
"""_generate_cache_header_key() creates a key for the given request path, adjusted for locales.
With this key, a new cache key is set via _generate_cache_key() for the HttpResponse
The subsequent anonymous request to this path hits the FetchFromCacheMiddleware in the
request capturing phase, which then looks up the headerlist value cached here on the initial response.
FetchFromMiddleWare calcuates a cache_key based on the values of the listed headers using _generate_cache_key
and then looks for the response stored under that key. If the headers are the same as those
set here, there will be a cache hit and the cached HTTPResponse is returned.
"""
key_prefix = key_prefix or settings.CACHE_MIDDLEWARE_KEY_PREFIX
cache_timeout = self.cache_timeout or settings.CACHE_MIDDLEWARE_SECONDS
cache = cache or get_cache(settings.CACHE_MIDDLEWARE_ALIAS)
cache_key = _generate_cache_header_key(key_prefix, request)
# Django normally varies caching by headers so that authed/anonymous users do not see same pages
# This makes Google Analytics cookies break caching;
# It also means that different anonymous session_ids break caching, so only first anon request works
# In this subclass, we are ignoring headers and instead varying on authed vs. anonymous users
# Alternatively, we could also strip cookies potentially for the same outcome
# if response.has_header('Vary'):
# headerlist = ['HTTP_' + header.upper().replace('-', '_')
# for header in cc_delim_re.split(response['Vary'])]
# else:
headerlist = []
cache.set(cache_key, headerlist, cache_timeout)
return _generate_cache_key(request, request.method, headerlist, key_prefix)
The Fetcher, which is responsible for retrieving the page from the cache, looks like this
class AnonymousFetchFromCacheMiddleware(FetchFromCacheMiddleware):
def process_request(self, request):
"""
Checks whether the page is already cached and returns the cached
version if available.
"""
if request.user.is_authenticated():
request._cache_update_cache = False
return None
else:
return super(SmarterFetchFromCacheMiddleware, self).process_request(request)
There was a lot of copying for UpdateCacheMiddleware, obviously. I couldn't figure out a better hook to make this cleaner.
Does this generally seem like a good approach? Any obvious issues that come to mind?
Thanks,
Ben
You may work around this by temporarily removing unwanted vary fields from response['Vary']:
from django.utils.cache import cc_delim_re
class AnonymousUpdateCacheMiddleware(UpdateCacheMiddleware):
def process_response(self, request, response):
vary = None
if not request.user.is_authenticated() and response.has_header('Vary'):
vary = response['Vary']
# only hide cookie here, add more as your usage
response['Vary'] = ', '.join(
filter(lambda v: v != 'cookie', cc_delim_re.split(vary))
response = super(AnonymousUpdateCacheMiddleware, self).process_response(request, response)
if vary is not None:
response['Vary'] = vary
return response
Also, set CACHE_MIDDLEWARE_ANONYMOUS_ONLY = True in settings to prevent cache for authenticated users.
I just added this SSL middleware to my site http://www.djangosnippets.org/snippets/85/ which I used to secure only my login page so that passwords aren't sent in clear-text. Of course, when the user navigates away from that page he's suddenly logged out. I understand why this happens, but is there a way to pass the cookie over to HTTP so that users can stay logged in?
If not, is there an easy way I can use HTTPS for the login page (and maybe the registration page), and then have it stay on HTTPS if the user is logged in, but switch back to HTTP if the user doesn't log in?
There are a lot of pages that are visible to both logged in users and not, so I can't just designate certain pages as HTTP or HTTPS.
Actually, modifying the middleware like so seems to work pretty well:
class SSLRedirect:
def process_view(self, request, view_func, view_args, view_kwargs):
if 'SSL' in view_kwargs:
secure = view_kwargs['SSL']
del view_kwargs['SSL']
else:
secure = False
if request.user.is_authenticated():
secure = True
if not secure == self._is_secure(request):
return self._redirect(request, secure)
def _is_secure(self, request):
if request.is_secure():
return True
#Handle the Webfaction case until this gets resolved in the request.is_secure()
if 'HTTP_X_FORWARDED_SSL' in request.META:
return request.META['HTTP_X_FORWARDED_SSL'] == 'on'
return False
def _redirect(self, request, secure):
protocol = secure and "https://secure" or "http://www"
newurl = "%s.%s%s" % (protocol,settings.DOMAIN,request.get_full_path())
if settings.DEBUG and request.method == 'POST':
raise RuntimeError, \
"""Django can't perform a SSL redirect while maintaining POST data.
Please structure your views so that redirects only occur during GETs."""
return HttpResponsePermanentRedirect(newurl)
Better is to secure everything. Half secure seems secure, but is totally not. To put it blank: by doing so you are deceiving your end users by giving them a false sense of security.
So either don't use ssl or better: use it all the way. The overhead for both server and end user is negligible.