I am playing around with Flask. I like that it is fairly thin and works for most of my requirements.
I would like to know what is your recommended way of retrieving the current logged in user. I would like every HTTP request, which is made, to pass/carry a token in the header, which is first retrieved by the login api
/user/login (params: username, password)
# returns {success: True, token: "<some-unique-string>"
Now is the subsequent APIs I would like to get the user object from the from passed token, like so
#app.route("/user/info", methods = ["GET"])
#apify
def user_get_info():
return {"name": current_user().name}
How could I have current_user read from the header without having to pass the request object every time ?
Any thoughts?
Every token is stored against a user. So you can make a query to get a user against a given token. Something like:
token = Token.query.get(token='token_value')
return jsonify({'name: User.query.get(id=token.user_id).name})
This can be done in one line as well but it totally depends upon your models and relationships.
Hope that helps. If I haven't understood your question correctly, do elaborate a little.
Related
I have a problem setting cookies in Django.
Basically I have 3 different cookie I wanna set:
Session ID
Access token
Refresh token
For some reason Access and Refresh tokens are set, but the Session ID (SSID) doesn't set. If I change key of "SSID" to for example "TEST_COOKIE" it passes and I can see it in dev tools. However I need SSID and for some magical reason it doesn't work.
Here's example of my code:
class AuthResponse(SuccessResponse):
def __init__(self, data={}, ssid='', access_token: str = '', refresh_token: str = '', **kwargs):
super().__init__(data, **kwargs)
self.set_cookie(key=settings.SESSION_COOKIE_NAME,
value=ssid,)
if access_token:
self.set_cookie(key=settings.ACCESS_KEY_COOKIE_NAME,
value=access_token,)
if refresh_token:
self.set_cookie(key=settings.REFRESH_KEY_COOKIE_NAME,
value=refresh_token,)
AuthResponse inherits from SuccessResponse which is based on DjangoJsonResponse, and DjangoJsonResponse eventually inherits from HttpResponse.
So the question is - what could cause of getting rid of "SSID" cookie?
I tried to look around and find if all the data appears in init function and apprently eveyrthing is fine. All data, ssid, access_token and refresh_token come through, but only "SSID" doesn't get set.
As well I tried to use "httponly" and "secure" while setting cookies, but it didn't help.
There was an idea that might be middleware affects somehow on this, however I don't know who to check this out...
Is there anyone familiar with this who can potentially make an advice of why is this happening?
I found the answer while working on localhost the SESSION_COOKIE_DOMAIN should not be used, so I made it in this way in settings.py:
if website_settings.current_instance != 'dev':
SESSION_COOKIE_DOMAIN = (
website_settings.session_cookie_domain
if website_settings.session_cookie_domain
else f".{SITE_DOMAIN}"
)
This way it saves all needed cookies and browser sees them.
I have a SPA app that contains an form with an upload file field. I have a rest API whose endpoints are protected via flask-extended-jwt JWT. To authenticate the REST endpoints I use #jwt_required. I want to authenticate the upload request as well.
Because of the client side I can't add an Authorization Bearer header so I thought to add the access token as a hidden field when submitting the form.
What is the best way to manually validate the JWT access token after I read it from the form?
class Upload(Resource):
def post(self):
#TODO: check for access token
access_token = None
if 'access_token' in request.form and request.form['access_token']:
access_token = request.form['access_token']
else:
message = json.dumps({'message': 'Invalid or missing token', 'success': False})
return Response(response=message, status=401, mimetype='text/plain')
if access_token:
#TODO: validate_token(access_token)
Thank you
Author of flask-jwt-extended here. That's a great question. There is currently no supported way to do that in the extension, the grabbing the token from the request and decoding it are tightly coupled together. This would be hard to de-couple because there is a lot of conditional things that are going on when the full decode chain runs. For example, checking the CSRF value only if the request is sent in via a cookie, or differentiating between an access and refresh token for the sake of the blacklisting feature.
A generalized function could be created, it's signature would look something like decode_and_verify_jwt(encoded_token, is_access_token=True, check_csrf=False). However, this would complicate the rest of the code in flask_jwt_extended and be a rather confusing function to use for the general case.
I think in this case it would be easier just to add a fourth lookup in the extension, so you could use something like:
app.config['JWT_TOKEN_LOCATION'] = ['headers', 'forms']
app.config['JWT_FORM_KEY'] = 'access_token'
# Use the rest of the application normally
If you want to make a ticket on the github page so I can track this, I would be happy to work on it.
I'm thinking of allowing a user to revoke previously issued tokens (yes, even though they are set to expire in 15 minutes), but did not find any way to do so using DRF-jwt.
Right now, I'm considering several options:
Hope someone on SO will show me how to do this out-of-the-box ;-)
Use the jti field as a counter, and, upon revocation, require jti > last jti.
Add user-level salt to the signing procedure, and change it upon revocation
Store live tokens in some Redis DB
Is any of the above the way to go?
We did it this way in our project:
Add jwt_issue_dt to User model.
Add original_iat to payload. So token refresh won't modify this field.
Compare original_iat from payload and user.jwt_issue_dt:
from calendar import timegm
from rest_framework_jwt.authentication import JSONWebTokenAuthentication
class CustomJSONWebTokenAuthentication(JSONWebTokenAuthentication):
def authenticate_credentials(self, payload):
user = super(CustomJSONWebTokenAuthentication, self).authenticate_credentials(payload)
iat_timestamp = timegm(user.jwt_issue_dt.utctimetuple())
if iat_timestamp != payload['iat']:
raise exceptions.AuthenticationFailed('Invalid payload')
return user
To revoke a token you just need to update the field user.jwt_issue_dt.
Can I restrict actions of my API to specific users if I generate a token like this:
from itsdangerous import TimedJSONWebSignatureSerializer as Serializer
expiration = 600
s = Serializer(current_app.config['SECRET_KEY'], expires_in = expiration)
return s.dumps({ 'id': kwargs.get('user_id') })
And the verification
#staticmethod
def verify_auth_token(token):
s = Serializer(app.config['SECRET_KEY'])
try:
data = s.loads(token)
except SignatureExpired:
return None # valid token, but expired
except BadSignature:
return None # invalid token
user = User.query.get(data['id'])
return user
I don't understand how this works and achieves security. The way I'm used to securing an API for example, a user wants to do HTTP PUT to /posts/10 I'd usually get the post's author ie user_id then query the database get the token for that user_id, if the request token matches the queried token then it is safe for the PUT. I've read this article and don't fully understand how it achieves security without storing anything in a database. Could someone explain how it works?
By signing and sending the original token upon login the server basically gives the front end an all access ticket to the data the user would have access to, and the front end uses that token (golden ticket) on all future requests for as long as the token is not expired (tokens can be made to have expiration or not). The server in turn knows the token has not been tampered with, because the signature is basically the encrypted hash of the users recognizable data (user_id, username, etc). So, if you change the token information from something like:
{"user_id": 1}
to something like:
{"user_id": 2}
then the signature would be different and the server immediately knows this token is invalid.
This provides an authentication method that exempts the server from having to have a session, because it validates the token every time.
Here is an example of what a token could look like (itsdangerous can use this format of JSON web tokens)
I am reading a djangobook and get questions about HttpResponseRedirect and render_to_response.
suppose I have a contact form, which posts data to confirm view. It goes through all the validation and database stuff. Then, as a usual way, I output the html with
return render_to_response('thank_you.html',
dict(user_code = user_code),
context_instance=RequestContext(request))
However, the book suggested "You should always issue a redirect for successful POST requests." because if the user "Refresh" on a this page, the request will be repeated. I wonder what's the best way to send the user_code along through HttpResponseRedirect to the thank_you.html.
Pass the information in a query string:
thank_you/?user_code=1234
Or use a session variable.
The problem with a query string is that the user can see the data.
When you send a redirect, you are sending the user back a response (a 302 HTTP response) and they are then making an entirely new request to the provided URL. That's a completely new request/response cycle so there is no way to supply data unless you save it in a session variable, cache, cookie etc.
What you can do instead of telling the user to redirect, is to call the view you want to show them yourself from within the same request (i.e. at the point you would issue the redirect) and then you could pass whatever you liked.