I'm writing my first django project and I'm trying to make it as basic as possible. Rather than authenticating users, for the time being, I'm using cookies to identify people (if my understanding of what I'm doing is correct).
In my views.py, I have a method that does the following:
request.session["username"] = request.POST.get('username')
How do I set request.session["username"] within tests.py?
request.session["username"] = "Barry" doesn't seem to work, and neither does self.client.session["username"] = "Barry". I've been trying a few things that I saw at https://docs.djangoproject.com/en/1.9/topics/http/sessions/#using-sessions-out-of-views but there is a good chance that I haven't done it properly as I don't really understand what I'm doing. I also found this: Setting a session variable in django tests which gave me NameError: global name 'import_module' is not defined when I tried to use it. Any help or suggest reading (preferably beginner level) is appreciated.
The documentation tells you how to use the session in the client. In particular, note the need to assign the current session to a variable before modifying it:
session = self.client.session
session['username'] = 'Barry'
session.save()
Related
My django app uses update_or_create() to update a bunch of records. In some cases, updates are really few within a ton of records, and it would be nice to know what got updated within those records. Is it possible to know what got updated (i.e fields whose values got changed)? If not, does any one has ideas of workarounds to achieve that?
This will be invoked from the shell, so ideally it would be nice to be prompted for confirmation just before a value is being changed within update_or_create(), but if not that, knowing what got changed will also help.
Update (more context): Thought I'd give more context here. The data in this Django app gets updated through various means (through users coming on the web site, through the admin page, through scripts (run from the shell) that populate data from a csv etc.). The above question is important mostly for the shell scripts that update data from csvs, hence a solution at the database/trigger/signal level may not be helpful here (I guess).
This is what I ended up doing:
for row in reader:
school_obj0, created = Org.objects.get_or_create(school_id = row[0])
if (school_obj0.name != row[1]):
print (school_obj0.name, '==>', row[1])
confirmation = input('proceed? [y/n]: ')
if (confirmation == 'y'):
school_obj1, created = Org.objects.update_or_create(
school_id = row[0], defaults={"name": row[1],})
Happy to know about improvements to this approach (please see the update in the question with more context)
This will be invoked from the shell, so ideally it would be nice to be
prompted for confirmation just before a value is being changed
Unfortunately, databases don't work like that. It's the responsibility of applications to provide this functionality. And django isn't an application. You can however use django to write an application that provides this functionality.
As for finding out whether an object was updated or created, that's what the return value gives you. A tuple where the second value is a flag for update or create
I have installed django_two_factor_auth successfully: token logins, backup tokens and SMS via Twilio all seem to work fine. My users will not tolerate having to enter their token for every login, though.
My needs are similar to those discussed in the following:
https://github.com/Bouke/django-two-factor-auth/issues/56
I wish to offer the user an option to defer OTP verification for 30 days after a successful verification.
To this end, I installed django_agent_trust. I patched AuthenticationTokenForm to add a BooleanField if django_agent_trust is installed:
(two_factor/forms.py, in AuthenticationTokenForm)
try:
from django_agent_trust import trust_agent
trust_this_agent = forms.BooleanField(label=_("Trust this browser for 30 days"),
required=False)
except:
pass
and I have been able to unconditionally set and reset the is_trusted flag by using django_agent_trust's django_agent_trust.trust_agent API.
The problem is figuring out where to capture the user's selected value of the BooleanField. I'm lost somewhere in the form wizard.
I would accept an answer questioning the wisdom of my overall approach if I think your argument makes sense. Is there something I'm missing here?
in the beginning
django_agent_trust seemed like a good shortcut for this use case. It already had secure cookie support, a feature of Django I'd never used before, plus all the convenience methods I thought I'd need.
I was able to get it working with a little extra work.
problem
The problem I ran into was that django_agent_trust validates the signed cookie only after the user is authenticated -- with an authenticated user from the request object. Since I was trying to minimize changes to django_two_factor_auth, I needed to decide whether or not to show the OTP form before authentication occurs.
solution
All the tools I needed were in django_agent_trust. I pulled the methods I needed out of its middleware and into a new utils.py, adding a 'user' argument to load_agent(). Then I was able to check the cookie against the validated-but-not-yet-logged-in user object from django_two_factor_auth's LoginView class.
Now django_two_factor_auth's LoginView can test for agent trust in has_token_step and has_backup_step, and everything works more or less as the author predicted 11 months ago...sigh.
I think adding this trust element might make sense as an enhancement to django_two_factor_auth. Juggling hacks to all these components seems like the wrong way to do it.
later
I took a cue from the django_otp project and added agent_trust as a "plugin" to two_factor. It seems usable and maybe a little easier to digest in this form. This worked for me, but I suspect there's a much better way to do it. Patches welcome.
I'm trying to write a unit test for my flask app for OpenID but upon calling
oid.try_login(<oid provider>, <params>)
I get an error:
RuntimeError: <class 'flask.testing.FlaskClient'> does not support redirect to external targets
So, like every good SO user, I looked around for some solutions:
Disguise oid provider using the NoExtRef flask extension. I'm not sure if this is possible at the app level since I assume flask-openid messes around with the oid url (and it just redirected me to the original page when I tried it). But this seems quite ugly since I'm making a code change strictly for a unittest.
Create my own oid server but this might still be an external redirect (I'll try this later as soon as I get desperate enough).
I guess another alternative is to ignore writing unit tests for login and just set the user in Flask.g using the awesome Flask test framework. But I'd prefer to keep the login unit tests.
There is an alternative - monkey-patch the open-id extension's try_login method:
class LoginTestMonkeyPatch(object):
def __init__(self, oid=None, default_response=None):
self.response = default_response
if oid is not None:
self.init(oid)
def init(self, oid):
oid.try_login = self.try_login
def try_login(self, *args, **kwargs):
# Do whatever you want to do here
If you are patching the login, you may not be testing it.
I had the same problem. For me the best solution was to disable the "log in required" part of the view.
I don't know if you are using Flask Login, but if you are you can bypass the #login_required so that you don't even need to worry about trying to login the user with something like:
def setUp
env = Environments(app)
env.from_object('config.Testing')
lm = LoginManager()
lm.init_app(app)
self.app = app.test_client()
Just a thought, I hope this helps you or someone else :)
P.S. This is my first post on Stack Overflow. Thanks to all the many posters that have helped me so much!
I am writing forum app on Django using custom session/auth/users/acl system. One of goals is allowing users to browse and use my app even if they have cookies off. Coming from PHP world, best solution for problem is appending sid= to every link on page. Here is how I plan to do it:
Session middleware checks if user has session cookie or remember me cookie. If he does, this most likely means cookies work for him. If he doesnt, we generate new session ID, open new session (make new entry in sessions table in DB), then send cookie and redirect user to where he is, but with SID appended to url. After redirect middleware will see if session id can be obtained from either cookie or GET. If its cookie, we stop adding sid to urls. If its GET, we keep them.
I plan to insert SID= part into url's by decorating django.core.urlresolvers.reverse and reverse_lazy with my own function that appends ?sid= to them. However this raises some problems because both middlewares urlresolvers and are not thread safe. To overcome this I created something like this:
class SessionMiddleware(object):
using_decorator = False
original_reverse = None
def process_request(self, request):
self.using_decorator = True
self.original_reverse = urlresolvers.reverse
urlresolvers.reverse = session_url_decorator(urlresolvers.reverse, 's87add8ash7d6asdgas7dasdfsadas')
def process_response(self, request, response):
# Turn off decorator if we are using it
if self.using_decorator:
urlresolvers.reverse = self.original_reverse
self.using_decorator = False
return response
If SID has to be passed via links, process_request sets using_decorator to true and stores undecorated urlresolvers.revers in separate method. After page is rendered process_response checks using_decorator to see if it has to perform "garbage collection". If it does, it returns reverse function to original undecorated state.
My question is, is this approach thread-safe? Or will increase in traffic on my forum may result in middleware decorating those functions again and again and again, failing to run "garbage collection"? I also tought about using regex to simply skim generated HTML response for links and providing template filters and variables for manually adding SID to places that are omitted by regex.
Which approach is better? Also is current one thread safe?
First of all: Using SIDs in the URL is quite dangerous, eg if you copy&paste a link for a friend he is signed in as you. Since most users don't know what a SID is they will run into this issue. As such you should never ever use SIDs in the url and since Facebook and friends all require cookies you should be fine too...
Considering that, monkeypatching urlresolvers.reverse luckily doesn't work! Might be doable with a custom URLResolvers subclass, but I recommend against it.
And yes, your middleware is not threadsafe. Middlewares are initialized only once and shared between threads, meaning that storing anything on self is not threadsafe.
I've created a small django project with three applications, and I'm now writing tests for one of them. I needed to pass some information between differente views and differents templates,but that information should not be visible to the user. My first attempt was to pass this informatio as hidden fields in a HTML form, but then it was pointed to me that that did not make it completely invisible. So, I stored this information in the request.session dictionary and it went all right.
That said, my problem arised while testing. According to the django documentation (http://docs.djangoproject.com/en/1.2/topics/testing/) when you have to modify the session dictionary during testing you should first store it in a variable, modify it, and then save the variable.
So my testing code is something like this:
class Test_Atacar(TestCase):
fixtures = ["testBase.json"]
def test_attack_without_troops(self):
red_player = Player.objects.get(color=RED)
self.failUnless(red_player != None)
session = self.client.session
session["player_id"] = red_player.id
session.save()
response = self.client.get("/espectador/sadfxc/", follow=True)
But when I run the python manage.py test, I get an AttributeError, saying that dict, has no attribute save().
I read somewhere else (http://code.djangoproject.com/ticket/11475) that I should try doing a self.client.get to any other URL BEFORE manipulating the session so that it would become a "real" session, but I kept getting the same AttributeError.
when you have to modify the session dictionary during testing you should first store it in a variable, modify it, and then save the variable
This line means that if you want to make some changes into some of the session variables, do not make them directly into session. Store the data in the variable, make changes in that variable and then put that variable into session dictionary. session is like any other dictionary.
#anand I know it's weird but it indeeds work. What I had to do to make it work, besides not manipulating directly the variable was to make a self.client.get("/dummy/") where dummy is an URL that uses a dummy view. This view only modifies the attribute of the request it gets as argument. Honestly, I don't know what goes on behind the scenes that makes this work