jpulgarin / django-tokenapi Goto Github PK

Currently, if the is_active flag on the User is set to false, the token API still let's them in like normal.

If I make a request without a username or password, the returned status code is 200, while it should be 400. As a result, an incorrect request is treated as a correct one in the frontend.

Ie /new.json should not 500 if you go directly to the URL.

right now, the only way to add a 'success' field is to manually add it to each response. JSONResponse should either have a success field by default, or there should be a JSONSuccess implementation.

I have a server that has HTTP Auth for non-production purposes, but I want the presence of the "user" and "token" params to take precedence over HTTP Auth in token_required().

I will end up changing token_required temporarily for my needs, but my suggestion here is to allow the developer to specify a preferred method if both HTTP Auth and Token auth is present.

My tokens seem to expire after a couple days, despite having this set to a much larger number in settings.py

I looked through the code, but didn't find any references to TOKEN_TIMEOUT_DAYS.

Is there a way a token can last longer than TOKEN_TIMEOUT_DAYS perhaps forever? After reading the code, I couldn't find a function that didn't perform the date checking.

Whenever a new request is made to the server using a token, a new Django session is created. It shouldn't matter because sessions are not used here, but it could overwhelm the session store whether that is a database or an in-memory cache. This could be fixed by not calling the login() function in the decorator and setting request.user directly

Hi.

I'll need some tokens to have arbitrary timeout, like some minutes for ones and "until revoked" for others. Any tip on how to implement this?

My plan is to use this with https://github.com/tomchristie/django-rest-framework, as said in encode/django-rest-framework#9

This package works with Python 3, but the caniusepython3 utility flags it as needing to be upgraded. That tool looks at the classifiers in setup.py, which this doesn't have. It should have some, especially 'Programming Language :: Python :: 2.7' and 'Programming Language :: Python :: 3'.

#
from django.http import HttpResponse
try:
    import simplejson as json
except ImportError:
    import json
#

# JSON helper functions

def JSONResponse(data, dump=True):
    return HttpResponse(
        json.dumps(data) if dump else data,
        mimetype='application/json',
    )

def JSONError(error_string):
    data = {
        'success': False,
        'errors': error_string,
    }
    return JSONResponse(data)

I'm trying to user the @token_required on an otherwise un-noteworthy view, but wasn't able to get it to work (would only return 403s). I ended up making my own decorator that users token_generator.check_token to verify the request.

Is anyone else using this successfully? Am I missing some step or was there some change recently?

My relevant code is https://gist.github.com/stickwithjosh/5f622336adefe24de17f

django-tokenapi 0.1.7 is broken in 1.6 because a deprecated API is used. The fix is actually already checked-in to master in commit d5cd7c1 but a new version needs to be pushed to PyPI. Can this be done?

I have a app both on Mobile and Web ,will @token_requied decorator intercept session based authentication? does tokenapi support web app?

currently, only '' is permitted in (r'', include('tokenapi.urls')), as the urls in tokenapi.urls all begin with ^. This should be changed to allow non blank root urls.

In the same vein as #36, I should not get a 200 status code if I a token is invalid. As a rule of thumb, { success: false } should almost invariably return a non 2XX status code; after all, the request was not successful.

To support my case, I make requests to my API on the client side using axios, which returns ES6 promises. If I call Api.validateToken().then(success).catch(failure), I expect failure to be called if I supply an invalid token. At the moment, I have to check for response.data.success===false in the success callback since a 200 status is returned in any case.

I believe this is a major improvement to an otherwise straightforward Django module.