Re: Modifying a ModelAdmin instance at runtime
> Your analysis is entirely correct, as far as I can tell. Setting > attributes on `self` in a per-request method of a `ModelAdmin` is not > concurrency-safe, and it should not be recommended or demonstrated in > the docs. If you'd be willing to file a bug (or, better, a PR) to fix > this documentation example, that would be excellent. Will do, thanks for the sanity check. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/AC15DBCF-3DE0-4B23-89BD-040188CA81C5%40ignorare.net. For more options, visit https://groups.google.com/d/optout.
Re: Modifying a ModelAdmin instance at runtime
I agree that setting self.exclude will set the instance attribute, thus hiding
the class attribute of the same name. However, it appears that a given
AdminSite instantiates each registered ModelAdmin once at registration time.[1]
The default AdminSite itself is a module global. Thus, any long-running,
multi-threaded Django application server (e.g. a threaded uWSGI process) might
be relying on a given ModelAdmin instance to serve multiple requests
concurrently. Neither AdminSite nor ModelAdmin appear to have any
thread-locality, suggesting that modifying self.exclude (or anything else) for
an individual request is a race condition waiting to happen.
I believe this is essentially a subtle documentation bug, although it's worth
asking whether there are any deeper assumptions about ModelAdmin or AdminSite
having any kind of request isolation.
Thanks,
Peter
[1]
https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L104
> On Nov 12, 2014, at 1:36 PM, Collin Anderson wrote:
>
> On Tuesday, November 11, 2014 3:24:48 PM UTC-5, Peter Sagerson wrote:
> The documentation of ModelAdmin.get_form()[1] demonstrates modifying
> self.exclude in order to modify the add/change form on a per-request basis.
> However, looking at django.contrib.admin, it seems clear that ModelAdmin is
> instantiated when it's installed, not for every request. It also doesn't
> appear to be a subclass of threading.local. Is there some reason this isn't a
> terrible idea or is the example just in error?
>
> Thanks,
> Peter
>
>
> [1]
> https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_form
>
> Hi Peter,
>
> I've never thought that way about admin classes before, but it should work
> correctly.
>
> In Python, setting self.exclude = ['something'] will set a _new_ attribute on
> on the object, the instance of the admin class, not the admin class itself,
> even if there's a matching attribute on the class with that name. You'll end
> up with two different exclude lists. One in self.__class__.__dict__ (aka
> vars(type(self))) (which is now pretty hidden) and one in self.__dict__ (aka
> vars(self)).
>
> Though, if you _mutate_ the original attribute, like
> self.exclude.append('something'), it will mutate the exclude list on the
> class.
>
> Collin
>
>
> --
> You received this message because you are subscribed to a topic in the Google
> Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/AmoUDtEefyA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/be985862-c203-4358-bc78-8988a295f733%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/2D8BB5C1-879F-4D10-9A79-98ECD26C682A%40ignorare.net.
For more options, visit https://groups.google.com/d/optout.
Modifying a ModelAdmin instance at runtime
The documentation of ModelAdmin.get_form()[1] demonstrates modifying self.exclude in order to modify the add/change form on a per-request basis. However, looking at django.contrib.admin, it seems clear that ModelAdmin is instantiated when it's installed, not for every request. It also doesn't appear to be a subclass of threading.local. Is there some reason this isn't a terrible idea or is the example just in error? Thanks, Peter [1] https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_form -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/06fc9478-c3ac-4ba4-ba18-2ea59c7767f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ANN: django-otp and friends: one-time passwords and trusted agents
I imagine that would work. Generally speaking, if you want to use a multi-page flow to atomically mutate some state (in this case auth status), you're pretty much into form wizard territory. For specific scenarios, there may be workarounds--potentially a bit sneaky and underhanded--that produce a similar effect. On Aug 9, 2013, at 2:08 PM, Jason Arnst-Goodrich wrote: > I thought about that and I didn't like that it logged them in if they failed > the OTP token. I'll probably use it for now. > > The only reason being I want them to do it in a single "attempt session". If > they login half way and leave for a couples minutes I want them to supply the > regular login credentials again. In other words I'm not comfortable leaving > them in the "half way logged in" state. > > Although... I bet there's a way to expire users who are two factor enabled > that are not validated yet... > > How about I wrap the django_otp.views.login with something like: > > if not validated: > if login time too old: > kill the session > redirect to login_view > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/b47ONAEWFos/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: django-otp and friends: one-time passwords and trusted agents
Hi Jason, The two-step verification flow should be a cinch. Try something like this: @login_required @otp_required(if_configured=True) def protected_view(request): ... I'm not sure I followed the question about the password field, although there is some deliberate behavior here (see django_otp/forms.py#119<https://bitbucket.org/psagers/django-otp/src/5b161522b1dc087a51a2dc43c563e6e14930e89f/django-otp/django_otp/forms.py?at=default#cl-119>). By default (as of Django 1.3), password fields are not populated when a form is re-rendered after failing validation. In the case of an OTP-enabled form, that's not necessarily what we want. If the user logged in successfully but failed OTP verification (or didn't provide a token), we want to acknowledge that the password was correct by leaving it in the field. If you're not seeing reasonable behavior in some scenario, let me know. Of course, if you're only using the two-step flow above, this will be moot. Thanks, Peter On Friday, August 9, 2013 11:54:01 AM UTC-7, Jason Arnst-Goodrich wrote: > > After being sidetracked with unrelated work I'm finally back to > implementing the OTP stuff. > > Just to update you on how I decided to go about the 'self service' side of > things - I'm basically using django-otp unchanged and I'm adding an > AuthProfile model that users have some control of. This is where I control > limiting them in what they can add - right now only a mobile device (TOTP) > and static backup codes. > > Everything is basically working. The decorators do what they say they will > do but I've reached another place where I can see things can either be > improved on django-otp's side or maybe some guidance can be given to lead > me in the right direction. > > The Login Page: > > I'm trying to make it so that users will only see a Username / Password > field initially. Then if they have OTP options configured, send them to > step 2. Currently the OTP login form shows the token and allows for > selection of a device intelligently. > > One issue (might be considered minor) is that if they login with this form > and fat finger or fail the OTP token their password stays filled in the > form. Removing the password is easy enough but then they have to type it > again and the token again which isn't ideal since it leads to possibly more > mistakes and frustration. > > I BELIEVE I can achieve this by digging into the Django auth code and > maybe some middleware. It seems like that would make sense - I've just not > dug into the gritty details of the system. > > Any tips on creating a 2 stage approach would be much appreciated. > > On Wednesday, July 3, 2013 1:34:31 PM UTC-7, Peter Sagerson wrote: >> >> I took part of this conversation offline to spare the list from the gory >> details, but the upshot was that verifying an OTP is logically a mutating >> operation on the verifying device, and thus is not really valid on an >> unsaved model object. I posted an update to the documentation to clarify. >> >> There were a couple of other questions down there that got lost, but >> they're more interesting to Django in general. Managing a heterogenous >> collection of model objects is indeed a little tricky, although it's >> definitely a solved problem: this is precisely what the admin interface >> does. Technically, it should be easy to derive an AdminSite that allows a >> user to manage their own devices, although integrating that cleanly into a >> broader site design is probably more trouble than it's worth. I suspect >> that your approach using ContentTypes is a good one--that's pretty much >> what they're for. >> >> When I first embarked on this project, I actually thought that device >> management was one of the primary goals. Initially, writing a plugin >> required not just a model class, but a collection of forms that could be >> used to create and manage that device. Eventually I decided that there were >> several good reasons not to go down this road. To take one example, a >> TOTPDevice is fairly generic and could be paired with any number of >> real-world provers. Google Authenticator is the main one I know about, but >> there are others out there and more will emerge. Each prover may have a >> unique setup flow with different required TOTP parameters, some of which >> can't be anticipated in advance. For that reason alone, I think that >> integrating any kind of management UI directly into the device definition >> is a dangerous layer violation. >> >> I'll back up for a minute and point out that--true to
Re: ANN: django-otp and friends: one-time passwords and trusted agents
f.digits, self.drift + > offset) == token: > if (offset != 0) and OTP_TOTP_SYNC: > self.drift += offset > self.save() > > verified = True > break > else: > verified = False > > return verified > > It some cases it might be nice to verify a token to a device that doesn't > actually exist (particularly for validating when users setup 2 factor auth > themselves). The easiest way to do this right now is to instantiate a Device > and invoke verify_token but if the time is offset it'll want to call save() > (which then throws an exception). > > So maybe only call save if it already exists? Or allow some parameter > controlling the save on the method? Or maybe provide a separate class method? > > > On Monday, July 1, 2013 10:14:35 PM UTC-7, Jason Arnst-Goodrich wrote: > I'm glad you saw my message - if nothing else just so you know this project > is appreciated. > > I've got it working with Google's Authenticator. > > I had initially planned to use another project out there for my OTP needs > (there's a small number of them that work 'out of the box') because yours > took a little extra effort to hook up. > > I ended up going back and using yours though because it's truly in another > class. I have the basics working right now. > > I have a couple of questions - I'm trying to make a self service system for > allowing users to enable two factor authentication. > > If I loop django_otp.devices_for_user to allow them to manage their existing > devices, It's hard to link to a details page for each device. It might help > to have a get_absolute_url() defined on the model (which can be overridden is > settings). Right now I'm piping it to a template filter using ContentTypes. > TBH, I'm pretty new to dealing with this pattern so I might be thinking about > it wrong. > > Lastly, what I'll probably end up doing is building a decorator that > basically says "require two factor auth if they have it turned on". > > I guess if I had a wishlist it would be to see a baseline for allowing uses > to manage their own OTP devices as well as that decorator built in. I > understand it's probably out of the scope of what you have right now. I'd > still like like to see something that ties it up nicely. That's basically > what I'm building right now except I don't trust my build to work in anyone > else's setup - although if I have time I'll see if I can go back and refactor > it. > > Anyways, thanks again for the work you've done - it's outstanding. > > On Monday, July 1, 2013 9:26:06 PM UTC-7, Peter Sagerson wrote: > Thanks, I'm glad you like it. I can look into some kind of demo, although > Authenticator support is pretty simple. The documentation already links to > Google's URI scheme[1], which has all of the details. All you have to do is > create a TOTP or HOTP device (usually the former), encode the key with > base32, build a URI as documented, and render a QR code for the user to scan. > Alternatively, the user can also type the base32-encoded key in manually. > > > [1] http://code.google.com/p/google-authenticator/wiki/KeyUriFormat > [2] https://pypi.python.org/pypi/qrcode > > > On Jun 28, 2013, at 10:23 AM, Jason Arnst-Goodrich wrote: > > > I just stumbled on this and it looks absolutely amazing. I do have one > > request though: can we get a sample project up that uses Google's > > authenticator (or anything else). > > > > This looks like the best solution for two factor authentication for Django > > but I don't think many people will know where to start when it comes to > > using it (myself included). > > > > On Wednesday, September 12, 2012 1:27:26 PM UTC-7, Peter Sagerson wrote: > > I recently released a suite of packages to support two-factor > > authentication in Django by way of one-time passwords. > > > > The core package is django-otp, which defines the framework and provides > > all of the shared APIs. Integration is possible at several levels, from > > low-level APIs (devices_for_user(), match_token(), etc.); to an > > AuthenticationForm subclass; to a replacement for Django's login view and > > an OTP-enabled admin site. Other niceties include the otp_required > > decorator, an analog to login_required. This is not an authentication > > backend: although it depends on django.contrib.auth for modeling purposes, > > it operates indep
Re: ANN: django-otp and friends: one-time passwords and trusted agents
Thanks, I'm glad you like it. I can look into some kind of demo, although Authenticator support is pretty simple. The documentation already links to Google's URI scheme[1], which has all of the details. All you have to do is create a TOTP or HOTP device (usually the former), encode the key with base32, build a URI as documented, and render a QR code for the user to scan. Alternatively, the user can also type the base32-encoded key in manually. [1] http://code.google.com/p/google-authenticator/wiki/KeyUriFormat [2] https://pypi.python.org/pypi/qrcode On Jun 28, 2013, at 10:23 AM, Jason Arnst-Goodrich wrote: > I just stumbled on this and it looks absolutely amazing. I do have one > request though: can we get a sample project up that uses Google's > authenticator (or anything else). > > This looks like the best solution for two factor authentication for Django > but I don't think many people will know where to start when it comes to using > it (myself included). > > On Wednesday, September 12, 2012 1:27:26 PM UTC-7, Peter Sagerson wrote: > I recently released a suite of packages to support two-factor authentication > in Django by way of one-time passwords. > > The core package is django-otp, which defines the framework and provides all > of the shared APIs. Integration is possible at several levels, from low-level > APIs (devices_for_user(), match_token(), etc.); to an AuthenticationForm > subclass; to a replacement for Django's login view and an OTP-enabled admin > site. Other niceties include the otp_required decorator, an analog to > login_required. This is not an authentication backend: although it depends on > django.contrib.auth for modeling purposes, it operates independently of the > normal authentication machinery. > > A given user may have zero or more OTP devices against which we can verify a > one-time password. The core project includes Django apps that implement > common devices such as HOTP and TOTP (compatible with Google Authenticator, > among others) and static passwords (typically used as backup codes). The > former include standard features such as tolerance and drift. Separately, > django-otp-yubikey provides support for YubiKey devices (locally or remotely > verified). django-otp-twilio provides support for Twilio's SMS service for > delivering codes by SMS. Implementing support for additional mechanisms is as > simple as subclassing an abstract model class and implementing a verification > method (and optionally a challenge method). Raw implementations of HOTP and > TOTP are provided for convenience along with a few other generally useful > utility functions. > > As a companion to these, I've also released django-agent-trust, which uses > Django 1.4's signed key APIs to tag user-agents that the user has identified > as trustworthy. In other words, this implements the "This is a private/shared > computer" option one often sees on sensitive sites. Features include > revocation and expiration (both absolute and by inactivity; globally, > per-user, and per-agent). django-otp-agents is a project that glues together > django-otp and django-agent-trust to assign trust to user-agents by way of > two-factor authentication (one of the most common scenarios, it seems). > > Documentation: django-otp, django-otp-yubikey, django-otp-twilio, > django-agent-trust, django-otp-agents > Bitbucket: django-otp, django-agent-trust > > As always, the as-is clause in the BSD license isn't kidding. It's early days > for these yet and while everything has been carefully documented and > unit-tested, not all of the code has had contact with the real world. > Feedback is always welcome. The Google group > https://groups.google.com/forum/#!forum/django-otp is available for > discussion and questions. > > Thanks, > Peter > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/b47ONAEWFos/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > For more options, visit https://groups.google.com/groups/opt_out. > > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Filtering queryset using two fields in one model
Assuming you're using Django 1.1, take a look at: http://docs.djangoproject.com/en/1.1/topics/db/queries/#filters-can-reference-fields-on-the-model On Dec 8, 2009, at 10:18 AM, pbzRPA wrote: > Hi, > > I am not sure if this is a really stupid question but how can you > filter a model by comparing two of it's own fields? > > for example: > > class X(models.Model): > id = models.IntegerField() > new_id = models.IntegerField() > > now I want to say X.objects.filter(id = new_id) > > Thanks > > -- > > You received this message because you are subscribed to the Google > Groups "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Admin why deleting related(null=True) objects?
Yes, Django always cascades deletes. There's talk about providing more
options in a future release, but for now it's kind of a problem. I
generally find this behavior potentially catastrophic, so I wrote an
intermediate model base class that clears all nullable foreign keys
before deleting an object:
http://www.djangosnippets.org/snippets/1231/
Note that this probably won't stop the admin app from warning about
the anticipated cascade.
On Oct 7, 2009, at 6:37 AM, x_O wrote:
>
> Hi
>
> My question that I'm getting right that situation. I've two models:
>
> class First(db.models):
>second_item = models.ForeignKey('Second',null=True)
>...
>
> class Second(db.models):
>...
>
> I've both models registered in admin.py as AdminModels.
>
> Why when I'm trying to delete some object created from "Second" class
> which is RELATED to other one created from "First" class, admin is
> telling me that will remove also that "First" object (relation in
> ForeignKey is null). I understand that when there is null=False
> attribute should remove it, by why when it is null=True?
>
> In my interpretation of that should just leave First object with
> 'second_item' = None.
>
> x_O
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Menu managements, current URL
Is request.path[1] what you want? You might also consider basing your menu context on the current view rather than the current URL. I typically define a view decorator that can attach any context information I need to the current request: def page_context(section): def decorator(func): def page_context_wrapper(request, *args, **kwargs): request.section = section return func(request, *args, **kwargs) return page_context_wrapper return decorator Although I usually have several context arguments and bundle them up into an object which gets assigned to request.page_context. This approach keeps the views url-agnostic. [1] http://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpRequest.path On Sep 29, 2009, at 1:24 PM, Maksymus007 wrote: > > I'm looking for simple way of managing menu - so my question is - how > i can get currently used URL? > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Permissions independent of models
The way I solved this was to write a custom auth backend that could
evaluate a collection of non-model permissions. By convention, I had
one permission per view. Some of these permissions were aliased to
corresponding model permissions and some of them were based on other
criteria. Essentially, this is a way to hide the unlimited
functionality of user_passes_test() behind the standard permission-
based authorization API. If you wanted to dynamically assign these non-
model permissions, I imagine you could create your own Permission
model with links to Users and Groups and use that in the backend code.
A brief, highly simplified example:
class MyAuthorizationBackend(object):
def __init__(self):
self.virtual_perms = {
'app.article_annotations': self.allow_annotation_view
}
def has_perm(self, user, perm):
"""
This is the auth backend API.
"""
if perm in self.virtual_perms:
return self.virtual_perms[perm](user)
else:
return False
def allow_annotation_view(self, user):
"""
Returns true if the given user is allowed to view annotations.
"""
pass
AUTHENTICATION_BACKENDS = (
'django.contrib.auth.backends.ModelBackend',
'path.to.MyAuthorizationBackend',
)
On Jul 27, 2009, at 4:58 AM, Júlio Cesar wrote:
>
> I did this same question on the wrong comunity for this, Django
> Developers. After an alert, here I am hoping than you help me, please.
>
> X
>
> There are some permissions that I would like to add in my project,
> associated with acess a some views, particularly.
>
> But, there's no a clean mode to do this, because all permissions are
> associated with ContentTypes, right?
>
> I thought in obscure forms, like force create a content type from an
> abstract class and in there use that permissions, but there is an
> 'djangonic' method of made this?
>
> Very thanks and sorry my bad.
> Júlio Cesar.
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
