Re: Security middleware for django for insecure (http) connections

[Jani Tiainen]

Hi,

Also there exists HTTPS devserver (at least one is 
https://github.com/teddziuba/django-sslserver ) which does it's job 
pretty well. Used it when had to demonstrate javascript location 
services (which do require HTTPS at least on chrome).


So I'm pretty convinced that this subject can be done without changes to 
Django core to demonstrate it's usefulness in real world use cases.


On 16.1.2018 9.17, Shai Berger wrote:

Hi Vishwas,

Can you state the circumstances in which this middleware will be
useful? Note that with the help of Let's Encrypt[1], a HTTPS
certificate is freely available to anyone, so there is no financial
barrier to using it.

Over and beyond the subject matter, is there anything preventing
implementation of your proposed middleware as an external package?
  If there is, please let us know, perhaps there is a missing API we
  need to add. If there isn't, then it would be better to do it that way
  first -- so your method can be tested in real use before we consider
  putting it into the framework.

Hope this helps,
Shai.

[1] https://letsencrypt.org/



--
Jani Tiainen

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/31abd456-aa2e-8fe8-d1b3-85ee8ac3302c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Mehmet Dogan]

Seems like I found a better keyword argument than fallback_to_model. For 
the following backends setting:

AUTHENTICATION_BACKENDS = (
'django.contrib.auth.backends.ModelBackend',  
'guardian.backends.ObjectBackend',
'roles.backends.RoleBackend',
)

And the ways to check:

user.has_perm('foo.change_bar', obj) 
# default: check all, model checker expected to NOT disown her child

user.has_perm('foo.change_bar', obj, backends=('object', 'role', ))  
# just check backends specified; 'role' for *.RoleBackend

Advantages:

   - One will not have to use package specific API for checking just the 
   object permissions, for example.
   - Cleaner and generic: allows backends re-use each other. For example, I 
   am writing a RoleBackend and can easily make calls to model or object 
   permission backends, in order not to reinvent the wheel.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f637e9ca-b345-4c0f-92e7-b80464e9b6da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Mehmet Dogan]

And I forgot; 3rd advantage:


   - The 3 backend methods mentioned above won't have to take an extra 
   kwarg such as fallback_to_model; thus backward compatible there.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7b494b07-bef1-4824-87f8-d010f9b5432a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManytoMany Field save_form_data has not support for through table

[Collin Anderson]

Hi Andrew,

Would allowing set() for through models help in your case?
https://github.com/django/django/pull/8981

Thanks,
Collin


On Mon, Jan 15, 2018 at 5:14 PM, Andrew Standley <
astand...@linear-systems.com> wrote:

> Greetings,
> I've been messing around with trying to update some custom forms to
> instead be model forms, and I ran into something that struck me as odd.
>
> ModelForm relies on the models fields to select a default form field, and
> to save the returned form data. However the ManytoManyField does not appear
> to have behavior for dealing with 'through' models. The save_form_data just
> calls `set` on the ManyRelatedManager, which errors out if a through model
> without auto_created=True is defined.
>
> As far as I can tell I either have to write a lot of boiler plate in my
> ModelForm (add a custom field, override the __init__, override save(),
> etc), or define a custom ManyToManyField which overrides save_form_data.
> This seems odd to me as the through model seems like the sensible place for
> any behaviour required by the extra fields it defines.
>
> The ManyToMany field has knowledge of everything needed to access the
> intermediate model's default manager. It would make perfect sense to me
> that to have to implement custom clear/add/remove methods on either the
> model or it's manager for any through models that defined extra fields, and
> then be able to plug-and-play with the ModelForm framework. So my question
> is:
>
> Is there any particular reason that save_form_data does not have some
> default behavior for through models?
>
> Cheers,
> Andrew
>
>
>
> --
> This message has been scanned by E.F.A. Project and is believed to be
> clean.
>
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/e1fe8354-e1d1-05a1-e433-6fcf7e46216a%
> 40linear-systems.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S5crVgjpsNMiU8gPbs%3DYjBmDwrmgMVi9fjLqxBDa%2B7-0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManytoMany Field save_form_data has not support for through table

[Andrew Standley]

Hi Collin,
    Thanks, that would indeed help in my case.

The save_form_data method of the ManyToMany field would still eventually 
need to be updated to have the ability to pass the through_defaults 
kwarg to set(). However none of the extra fields on my intermediate 
model are required so that patch would definitely help clean up the code 
in my situation.


I'll patch our test server and see if everything runs smoothly and keep 
an eye that pull request.


Cheers,
    Andrew


On 1/16/2018 8:39 AM, Collin Anderson wrote:

Hi Andrew,

Would allowing set() for through models help in your case? 
https://github.com/django/django/pull/8981 



Thanks,
Collin


On Mon, Jan 15, 2018 at 5:14 PM, Andrew Standley 
mailto:astand...@linear-systems.com>> 
wrote:


Greetings,
    I've been messing around with trying to update some custom
forms to instead be model forms, and I ran into something that
struck me as odd.

ModelForm relies on the models fields to select a default form
field, and to save the returned form data. However the
ManytoManyField does not appear to have behavior for dealing with
'through' models. The save_form_data just calls `set` on the
ManyRelatedManager, which errors out if a through model without
auto_created=True is defined.

As far as I can tell I either have to write a lot of boiler plate
in my ModelForm (add a custom field, override the __init__,
override save(), etc), or define a custom ManyToManyField which
overrides save_form_data. This seems odd to me as the through
model seems like the sensible place for any behaviour required by
the extra fields it defines.

The ManyToMany field has knowledge of everything needed to access
the intermediate model's default manager. It would make perfect
sense to me that to have to implement custom clear/add/remove
methods on either the model or it's manager for any through models
that defined extra fields, and then be able to plug-and-play with
the ModelForm framework. So my question is:

Is there any particular reason that save_form_data does not have
some default behavior for through models?

Cheers,
    Andrew



--
This message has been scanned by E.F.A. Project and is believed to
be clean.


-- 
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 *MailScanner has detected definite fraud in
the website at "groups.google.com". Do /not/ trust this website:*
https://groups.google.com/group/django-developers
.
To view this discussion on the web visit *MailScanner has detected
definite fraud in the website at "groups.google.com". Do /not/
trust this website:*

https://groups.google.com/d/msgid/django-developers/e1fe8354-e1d1-05a1-e433-6fcf7e46216a%40linear-systems.com

.
For more options, visit *MailScanner has detected definite fraud
in the website at "groups.google.com". Do /not/ trust this
website:* https://groups.google.com/d/optout
.


--
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 *MailScanner has detected definite fraud in the 
website at "groups.google.com". Do /not/ trust this website:* 
https://groups.google.com/group/django-developers 
.
To view this discussion on the web visit *MailScanner has detected 
definite fraud in the website at "groups.google.com". Do /not/ trust 
this website:* 
https://groups.google.com/d/msgid/django-developers/CAFO84S5crVgjpsNMiU8gPbs%3DYjBmDwrmgMVi9fjLqxBDa%2B7-0g%40mail.gmail.com 
.
For more options, visit *MailScanner has detected definite fraud in 
the website at "groups.google.com". Do /not/ trust this website:* 
https://groups.google.com/d/optou

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Mehmet Dogan]

I updated my patch:

https://github.com/django/django/pull/9581

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b309e677-816b-4c5f-a2d1-e642d6c3551a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report — January 12, 2018

[Josh Smeaton]

Welcome, and nice work! I've seen some of the reviews you've made and 
you're straight into the deep end.

On Saturday, 13 January 2018 04:01:06 UTC+11, Carlton Gibson wrote:
>
> Hi all, 
>
> With help from Tim, Aymeric and Frank, I got started on the fellowship 
> this week. 
> (Thank you all!)
>
>
> I've Reviewed Patches on: 
>
> https://code.djangoproject.com/ticket/24747 -- Allowed transforms in 
> QuerySet.order_by()
> https://code.djangoproject.com/ticket/29002 -- Corrected cached template 
> loader docs about when it's automatically enabled
>
> https://code.djangoproject.com/ticket/28977 -- Change Local Memory Cache 
> to Use LRU
> https://code.djangoproject.com/ticket/29004 -- Add optional database view 
> support to inspectdb
> https://code.djangoproject.com/ticket/28761 -- Document prefixes in 
> InlineFormsets
> https://code.djangoproject.com/ticket/28885 -- Bottom parts of 
> "Congratulations!" page cut off internationalized content
>
>
> I'm still finding my feet (exactly how things are done etc) so all input 
> is welcome and appreciated (!!!)
>
> Kind Regards,
>
> Carlton
>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/da0e883c-80ff-4626-b06a-092bc001b187%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Security middleware for django for insecure (http) connections

[Josh Smeaton]

HTTPS is enough. Despite that, how would you handle the **client** doing 
decryption and encryption? I don't think this is an idea you should pursue, 
especially if your expertise is not in security.

On Tuesday, 16 January 2018 10:03:00 UTC+11, Vishwas Mittal wrote:
>
> Hello everyone,
>
> I am a new contributor to django, and would like to propose a new 
> middleware to django that can provide some degree of security for HTTP 
> connections by encrypting the data to be sent in response.
>
> This middleware will work on the principles of HTTPS but the main 
> difference is there will no certification authority involved.
>
> This will include the middleware inplementation and also a user side code/ 
> implementaion which can be used to complete the encryption-decryption 
> couple.
>
> Please present your thoughts and make necessary suggestions regarding this.
>
>
> Regards
> Vishwas
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/184bbb3a-b7b8-4ef0-bc02-b5e888ffa549%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report — January 12, 2018

[Carlton Gibson]

On Wednesday, 17 January 2018 00:34:11 UTC+1, Josh Smeaton wrote:
>
> Welcome, and nice work! I've seen some of the reviews you've made and 
> you're straight into the deep end.
>

Thanks Josh. Too deep maybe 🙂 — but yes. 

I'm just happy to be able to work on Django. It's given me SO much. 

Right, to work...  

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/30d212d8-61ca-4eb1-b7e1-3f3fd08573d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.