Re: Redesign of djangoproject.com?

[Atul Bhouraskar]

On 2 May 2012 11:56, Buddy Lindsey, Jr.  wrote:

> um, not sure what happened to part of my response, but to summarize a
> missing paragraph I would like the design to consider showing more of the
> community as well.
>
>
> Buddy Lindsey, Jr. wrote:
>
>
> Russell Keith-Magee wrote:
>
>
>
> * One of my personal goals for this redesign is to give more
> visibility to community resources. Over the last 6 years, we've had a
> number of unofficial projects come and done great service for the
> community -- django people, several packaging indices, and so on.
> However, many of these projects have died on the vine. I suspect one
> of the reasons that these projects has died is that they've never
> really been considered first class members of the community, and so
> it's mentally easy to abandon them rather than seeking to hand them
> off to a new maintainer. The only place I can see in Giovanni's
> design for this sort of community content would be to bury it in the
> footer, or on a separate part of the community page.
>
>
>
>
> I came to Django from the Rails community and while I prefer Django
> over Rails one thing I was disappointed with on arrival was I didn't
> know "where" the Django community was, still not sure I do. Maybe the
> django community is quiter than the Rails community is, but if I
> didn't actively scour the internet I would think the community is dead
> which is one of my evaluations of using a technology.
>
> my 2 cents on the community aspect.
>
>
I agree. One part could be to integrate the google group(s) into the site
using google web elements e.g http://www.google.com/webelements/#!/groups

Regards,

Atul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ModelForms and the Rails input handling vulnerability

[Atul Bhouraskar]

Hi All,

I can see two separate (but related) problems that need to be solved:

1. Ensure that sensitive fields are not accidentally exposed to users (e.g
when a database model is updated to include one), and
2. Provide a means to confirm whether the fields as rendered and submitted
exactly match the intent of the form.

This is my proposal for problem 1:

Add an "is_sensitive" or similarly named boolean attribute to model fields.
This field would be False by default and would be set to True for fields
that contain sensitive data e.g:

class Article(models.Model):
  text = models.TextField()
  secret_notes = models.TextField(is_sensitive=True)

Now a ModelForm would by default exclude any field that is marked as
sensitive, unless it is explicitly included via the "fields" attribute.

The advantage of the above is that it allows mechanisms other than Forms to
enforce rules associated with sensitive data and could potentially be
double checked while being rendered as well. For developers who don't care
about sensitive data, nothing changes, unless the is_sensitive attribute is
made True by default (which would be a pain).

Regards,


Atul

On 14 June 2012 10:18, Carl Meyer  wrote:

> On 06/13/2012 06:12 PM, Doug Blank wrote:
> > On Wed, Jun 13, 2012 at 5:05 PM, Carl Meyer  wrote:
> >> On 06/13/2012 02:55 PM, Peter wrote:
> >>> Can I throw in option 5:
> >>>
> >>> We leave ModelForms as they are, but emit a warning if you only
> >>> partially render the form?
> >>>
> >>> I'm not sure how feasible this is, but presumably we could keep track
> of
> >>> which fields have been rendered for a given form instance?
> >>>
> >>> That way, if you render the whole form ( {{ form.as_p }} ) you'll see
> >>> your new sensitive field appear in the page. If you manually render the
> >>> form, you'll get a warning.
> >>
> >> I've thought about this. The main problem is that the implementation is
> >> quite difficult in practice: at what point do you perform the check?
> >> There isn't any such thing as an "ok, I think I'm all done rendering
> >> this form now, tell me if I did it right" hook.
> >
> > I, too, was thinking about this kind of solution. In fact, it came up
> > for me the other day because I had forgotten to exclude a field that I
> > did not have on the form, and so the value ended up getting wiped out
> > when I saved. So, perhaps a solution that prevented others from adding
> > fields could also be a solution that checked to make sure that the
> > form was editing all fields it should be.
> >
> > What about a {% validate %} tag in the form which would do a runtime
> > check to make sure that all non-excluded fields had been rendered?
>
> Yeah, this would be a cleaner way to implement the check. I'd like to
> see it proved out as a third-party add-on before discussing it for core.
> One of the unresolved issues in my mind is what it should actually _do_
> if you haven't rendered all the fields on the form (blow up in DEBUG
> mode only? Just a call to warnings.warn?).
>
> And since it's opt-in (and easy to forget or not bother with) I'm not
> sure that by itself it's a satisfactory solution to the original problem
> of implicit Meta.fields.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URLField should allow scheme to be empty

[Atul Bhouraskar]

As per RFC 3986 (see section 4, in particular 4.2) all of the following are
valid:

Absolute URI
http://www.example.com/images/xyz.png

Network path reference
//www.example.com/images/xyz.png

Suffix reference (frowned upon but valid?)
www.example.com/images/xyz.png

Absolute path reference
/images/xyz.png

Relative path references
images/xyz.png
../images/xyz.png

Should URLField allow all of them? Or do we need options to selectively
allow/disallow URL components? Or maybe have AbsoluteURLField,
NetworkPathURLField etc?

Only an absolute URI is *always* relevant. Network path references (and
relative path references) are only relevant in the context of a web page
loaded in a browser (e.g. a URL to be rendered within the context of an
email only makes sense if absolute).

In any case (in my opinion) the URLField should not automatically add a
missing http: - it should either reject the contents or allow it as per
documented rules.

Atul


On 4 April 2013 07:26, Alex Ogier  wrote:

> Don't add an option, it's not needed. URLs with blank schemas are valid,
> it's just a bug that Django adds 'http://' in that case. So make a
> ticket, +1 from me.
>
> Best,
> Alex Ogier
>
>
> On Wed, Apr 3, 2013 at 4:24 PM, Juan Pablo Martínez wrote:
>
>> I love it.
>> If URLField has an option like "scheme_required=False" or something like
>> that.
>> No behaviour is the "correct", append or not append scheme. The option to
>> our needs seems to be more correct.
>>
>> Regards,
>>
>>
>> On Wed, Apr 3, 2013 at 5:14 PM, SteveB  wrote:
>>
>>> How to avoid those browser warnings about mixing secure and insecure
>>> content on a web page?
>>> Wouldn't it be great to be able to specify a URL for a resource (be it a
>>> script, image, iframe etc.)  such that if the current page is insecure
>>> (using a http:// scheme) the content would be fetched using the same
>>> scheme?
>>> And when the current page is secure (using a https:// scheme) the
>>> resource would also be fetched as if it had a https scheme?
>>>
>>> Well you can, just leave out the scheme in the URL. That is, specify it
>>> as "//example.com/some/path/" and the browser will apply the same
>>> scheme as the parent page.
>>>
>>> Great! - But, it is not possible to specify a URL such as this in a
>>> Django URLField. Thanks to https://code.djangoproject.com/ticket/5331,
>>> a blank scheme will be cause the field verification to insert "http" as the
>>> scheme, and you lose the flexibility described above.
>>> It is currently not possible (in Django 1.5.1) to get a URLField
>>> validating with a blank scheme, so the ability to specify a URL for a
>>> resource which can be follow the scheme of the parent page is not possible.
>>>
>>> I content that the 5331 ticket may not have taken into account the
>>> flexibility which the empty scheme offers on web pages, and I urge that it
>>> be reconsidered.
>>>
>>> What do folks think?
>>> SB
>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>
>>
>> --
>> juanpex
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Adding a URL tagging feature

[Atul Bhouraskar]

I've received a few comments on Ticket #25409 and so I'm opening up the
discussion here.

The pull request is https://github.com/django/django/pull/5309

Apologies for the long post, just wanted to be as clear I could!

The objectives of the discussion are to determine:
1. Is this something that could be merged in before the other URL
re-factoring work (
https://groups.google.com/d/topic/django-developers/9AqFxIIW2Mk/discussion)
I personally think that we can as the code changes are minimal.
2. Does this approach conflict with/complement/replace the 'decorators'
approach proposed in the URL rework project. There is a comparison of the
pros and cons of each approach below. Looking at the code on that branch it
appears simple for me to be able to merge it in there.

== Synopsis ==

Often (usually in middleware) processing has to be applied to certain URLs
only eg CORS.

The usual way to specify this would be to create an additional set of regex
patterns identifying these urls - eg.

CORS_URLS_REGEX = r'^/api/2/.*$'

JSONP_URLS = r'^/api/1/.*$'

PRIVATE_URLS = r'/(private|api)/.*$'

Each middleware then typically matches the incoming request URL to the
regex and determines whether it is to be selected for processing by it.

This approach has several limitations including:
* It violates DRY as the regexes in the settings have to be synced with the
actual URL patterns
* Matching multiple patterns either requires the user to create complex
regexes or the app/middleware writer has to essentially reinvent URL
patterns - poorly.

== The Proposal ==

Add an optional *tags* keyword argument to django.conf.urls.url allowing a
URL to be optionally tagged with one or more tags which can then be
retrieved via HttpRequest.resolver_match.tags in the middleware / view (or
any code with access to urlpatterns - not necessarily in the context of a
request). Probably easiest to explain via examples:


urlpatterns = [
url(r'^$', views.home, name='home'),
url(r'^private/$', include(private_patterns), tags=['private']),
url(r'^api/1/', include(api_v1_patterns), tags=[
'api', 'private', 'jsonp',
]),
url(r'^api/2/', include(api_v1_patterns), tags=[
'api', 'cors', 'private',
]),
]

api_v1_patterns = [
url(r'^list/books/$', views.list_books, name='list-books'),
url(r'^list/articles/$', views.list_articles, name='list-articles',
tags=['public]),
...
]

api_v2_patterns = [
url(r'^list/books/$', views.list_books, name='v2-list-books'),
url(r'^list/articles/$', views.list_articles, name='v2-list-articles',),
...
]

In the above patterns all URLs under /private/ are tagged 'private', all
URLs under /api/1/ are tagged 'api', 'jsonp' and 'private'.


Some examples to show how you can access and use tags

Example Middleware:

class PrivatePagesMiddleware(object):
def process_view(self, request, view_func, view_args, view_kwargs):
"""
For any url tagged with 'private', check if the user is
authenticated. The presence of a
'public' tag overrides the 'private' tag and no check should be
performed.
Authentication depends on whether the URL is marked as 'cors' or
not. 'cors' urls
use HTTP header token authentication
"""
tags = request.resolver_match.tags
if 'private' in tags and not 'public' in tags:
if 'cors' in tags:
# CORS requests are authenticated via tokens in the headers
# check auth tokens
...
if not authenticated:
  return HttpResponseForbidden()
elif not request.user.is_authenticated():  # normal django auth
return redirect('login')

class CorsMiddleware(object):
def process_view(self, request, view_func, view_args, view_kwargs):
if 'cors' in request.resolver_match.tags:
# continue CORS processing

def process_response(self, request, response):
 if 'cors' in request.resolver_match.tags:
# continue CORS processing


Example Management command:

commands/exportapi.py

"""
Javascript API code generator
Iterate through urlpatterns, for each url tagged with 'api' export a
Javascript function
that allows js code to call the api function. Depending on whether the
pattern is tagged
'jsonp' or 'cors' write the corresponding type of function
"""

def get_api_urls(urlpatterns, api_type):
for pattern in urlpatterns:
 # check if pattern has the 'api' tag and the api_type tag
 
 if is_api_type:
 yield pattern


class Command(BaseCommand):
def handle():
 for api_pattern in get_api_urls(urlpattrns, 'jsonp'):
  # write JSONP javascript function to stdout

 for api_pattern in get_api_urls(urlpattrns, 'cors'):
  # write CORS javascript function to stdout

manage.py exportapi > api.js

-

The actual code c

Re: Adding a URL tagging feature

[Atul Bhouraskar]

Thanks Marc& Shai for taking the time to look at this. Apologies for the
late response as I was busy.

Yes, I agree that decorators can be used to tag urls, however I think that
the way that the URL rework code applies decorators can be improved.

The reason I've called the decorators approach 'heavyweight' is because the
decorators are applied by the ResolverMatch object and so all of the
decorator code (not just the decorated function) will run for every
decorator for every request. Normally decorator code (if applied directly
to the view) would only run at module import time and only the wrapped
function code is executed during a request and there is no reason to look
at performance. But placing all the functools wrapping helper code into the
'hot' request path should be avoided if possible.

I've gone over the URL rework branch in some detail and I think we
can/should move the application of decorators from inside the ResolverMatch
to the ResolverEndpoint so that the decorators are applied only once when
the resolver is instantiated using get_resolver(). I'm happy to submit a
patch for that however I'm not entirely sure which tree is the reference
one for the URL rework. Is it this one?
https://github.com/jaddison/django/tree/gsoc2015_url_dispatcher

Atul


On 29 September 2015 at 07:06, Shai Berger  wrote:

> Assume decorators, then, more or less:
>
> def tagged(*tags):
> def decorate(view):
> @functools.wraps(view)
> def decorated(*args, **kw):
> view(*args, **kw)
> decorated.tags = tags
> return decorated
> return decorate
>
> (taking care to define a new function in the decorator so that you can use
> the
> same view with differnet tags in different URLs)
>
> That doesn't seem too heavyweight to me. Am I missing something?
>
> Assuming not, the decorator defined above can be used already with current
> production versions of Django for single URLs, and after the URL rework
> also
> on includes.
>
> Your examples become
>
> # Already today
> api_v1_patterns = [
> url(r'^list/books/$', views.list_books, name='list-books'),
> url(r'^list/articles/$', tagged('public')(views.list_articles),
>  name='list-articles'),
> ...
> ]
>
> # After URL rework
> urlpatterns = [
> url(r'^$', views.home, name='home'),
> url(r'^private/$', include(private_patterns),
>  decorators=[tagged('private')]),
> url(r'^api/1/', include(api_v1_patterns), decorators=[
> tagged('api', 'private', 'jsonp'),
> ]),
> url(r'^api/2/', include(api_v1_patterns), decorators=[
> tagged('api', 'cors', 'private'),
> ]),
> ]
>
>  taking Marc's doubts (which I agree with) into account, and seeing as 1.9
> is
> already feature-frozen, I think that the proper way forward for this
> feature
> is to live out of core.
>
> If I am missing something, and it is hard to implement it out of core,
> please
> explain.
>
> HTH,
> Shai.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHdnYztTtpNK6uWv3cw12Cocj1GWzMwQyPKa0hzuo8JqZ22Uig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #20824 - Email-based auth contrib module; some help required

[Atul Bhouraskar]

Won't normalize_email will allow two distinct users u...@example.com and
u...@example.com to be created? Case insensitive searches will return
multiple users for a 'get'.

Perhaps the closest we can get is to ensure that any user created using
Django functions is saved with a consistent case transformation and then
perform an *exact* search after applying the same transformation to the
input?

One idea could be to add a 'transform_email' or similar hook that by
default calls normalize_email and ensure that it is applied both to data
that is about to be saved and to search terms. Projects that wish to change
the behaviour can simply override transform_email to perform for example
lowercase conversion if so desired.

Atul


On 27 February 2014 11:43, Russell Keith-Magee wrote:

>
> On Thu, Feb 27, 2014 at 8:31 AM, Curtis Maloney <
> cur...@acommoncreative.com> wrote:
>
>> Doesn't the UserManager already have a "normalize_email" method which
>> lower-cases the domain and leaves the mailbox name alone?
>>
>> IMHO It's "proper" to leave it this way by default, and probably mention
>> in the docs it's used so if you want to change it, that's the hook.
>>
>
> It does - assuming you use User.objects.create_user() to create all your
> users. However, the UserCreationForm doesn't use this (and hasn't ever used
> this); it also doesn't account for fixtures, or any other path into the
> database that might exist.
>
> So - while normalising case is probably a good idea, and should probably
> be added to the Create/Update User form, the searches will still need to be
> case insensitive.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq84_1%2B_oVDUAeHyXoFGTirsZEgejaY6q4hNK0EZGpqS96Wg%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHdnYzuJw_g2ZmzoQ%2B51v5BC1FcD0wN4TgazFoJgT1ZVEYDOWA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The greatest proposal yet: rename this damn group

[Atul Bhouraskar]

+1 for Django Contributors.

This also aligns with all the documentation on djangoproject.com where
there is an entire section on 'Contribution'.

We even have a "Contributor Licence Agreement'.

Atul


On 9 September 2014 01:24, Carl Meyer  wrote:

> On 09/08/2014 08:56 AM, Aymeric Augustin wrote:
> > 2014-09-08 16:21 GMT+02:00 Thomas Leo  > >:
> >
> > +1 for django-contributors
> >
> >
> > That would be "Django Contributors" since we're talking about changing
> > the display name of the group, not its email address.
> >
> > It's a good proposal.
>
> I agree. I don't see any reason not to try this.
>
> Who has access to the Google Groups admin?
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/540DCA25.6010908%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHdnYzuyrTUrj74R5i6cqBEENeFKq%3D0SVMp-0U5ye22SM__qNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.