Re: about ticket 28588- has_perm hide non-existent permissions

[Florian Apolloner]

Hi,

On Friday, September 29, 2017 at 7:00:41 PM UTC+2, moshe nahmias wrote:
>
> 3. Return False if the permission doesn't exist means that we go through 
> the same path as a regular user, since (at least on 
> auth.backends.ModelBackend) we check already if the user is superuser and 
> if so we return all the permissions (I suppose it's only permissions that 
> exist) it means we only need to remove the check at the start to see if the 
> user is superuser.
>

Removing this check would be highly backwards incompatible for 3rd party 
permission backends.

​I don't think the performance will be that much of a problem, but since 
> you think it might I think i will need to check it and report the results 
> back unless there is a preference for one of the other solutions. either 
> way it will be a good thing to check.​
>

There will probably not be a big performance drop for the builtin ones, but 
we do not know anything about 3rd party (ie ldap etc) 

-- 
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/e14b6ff5-598d-4605-9e76-26df86971366%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MariaDB, official support

[Claude Paroz]

Hi,

I would like to push a bit for that functionality in Django 2.1. Adam, any 
progress?

In https://github.com/django/django/pull/7778, you talked about a better 
plan. Show us your plan, please :-)

Claude

-- 
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/2c525ee9-ed0c-4b4b-9dd2-f4750496b2c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#28636 - Translation language preference without restriction to `settings.LANGUAGES`

['Denis Anuschewski' via Django developers (Contributions to Django itself)]

Here is the PR .

I think it would be beneficial to have an optional boolean flag in order to 
check the language preference against `LANG_INFO` rather 
than `settings.LANGUAGES`. It would allow one e.g. to get the preference 
and add a translation fallback for specific languages (with a custom 
LocaleMiddleware), e.g. when it differs from `settings.LANGUAGE_CODE`. 
Currently it's not possible when you get a language that is not listed 
in `settings.LANGUAGES`, because then you always 
get `settings.LANGUAGE_CODE`, which is not the wanted result in such a use 
case.

Or is there another way for achieving this without modifying the django 
core? Overwriting `settings.LANGUAGES` didn't work for me because it 
activated translation for all languages (I just want a fallback).

-- 
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/c99ebbe1-95a4-4309-8e72-deca0f6a7071%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Nick Zaccardi]

There are cases where corporate security policies require (regardless of 
the actual security they provide) which require a <24hr link. Here is a 
x/post from this ticket :

I do want to explain why this doesn't meet the 1% of use cases. When I 
> originally reported this I was working on a password reset feature in a 
> different app (a large corporate financial application) which has very 
> specific policies on passwords, password resets, and the validity time of 
> both. From a contractual perspective (regardless of user experience) >24hr 
> link would be a break in policy or worse a violation of contractual 
> obligation to implement a <24hr link. For most up to 2 days is fine, for 
> some, regardless of the real-life implications of the policy, it is a big 
> deal.
>

On Saturday, September 23, 2017 at 9:41:17 AM UTC-5, Luke Plant wrote:
>
> Hi Zach,
>
> To be clear, I'm not totally opposed to the change. There could certainly 
> be advantages to updating the code, especially if we move to 
> TimestampSigner.
>
> However, from a quick look, I'm not sure if TimestampSigner will be 
> possible - we want the hashed value to incorporate some internal data, but 
> don't want that internal data to be part of the signed message that Signer 
> produces (for various reasons, including the fact that we want to keep the 
> URL as short as possible for maximum compatibility). I think we should also 
> be careful not to change the public interface of 
> PasswordResetTokenGenerator, since people may have subclassed it, which 
> limits the amount of cleanup you can do here. 
>
> I imagine that changing the timestamp to support better precision will 
> also create work for people upgrading (the setting change, plus URLconf 
> changes). 
>
> What I am suggesting is that we should seriously consider whether all this 
> is worth it given the extremely marginal security benefits.
>
> Regards,
>
> Luke
>
> On 23/09/17 04:33, Zhiqiang Liu wrote:
>
> Luke, 
>
> thanks for the long explanation. I see your points here. I actually saw 
> the make token function and was thinking about it what is the best way to 
> do with that. I think most people here feel there's need to at least allow 
> some flexibility for the time out since there will be cases under a day is 
> needed.
> I will keep this discussion for a couple of more days to see if we can get 
> consensus and how we should implemented if needed.
>
> Zach
>
> On Friday, September 22, 2017 at 3:04:01 PM UTC-4, Luke Plant wrote: 
>>
>> I would be +1 to what Adam wrote from me i.e. just allow the value to 
>> accept floats.
>>
>> However, I don't think it will work due to the way that we round the 
>> precision of timestamps to days 
>> .
>>  
>> This was done partly to reduce the number of characters needed to express 
>> the timestamp, to keep URLs as short as possible. We would  have to change 
>> the mechanism to store more precision into the timestamp. This would result 
>> in an upgrade 'bump' for users (i.e. links generated before the upgrade 
>> would become invalid after upgrade).
>>
>> However, I really question whether we need any change here, and whether 
>> it would be a good idea.
>>
>> Having a short expiration time (less than 1 hour) could cause major 
>> problems for some people - plenty of systems introduce 5 or 10 minute 
>> delays in mail delivery, and with some people's internet connection it can 
>> take several minutes to open a web page. This also means that some people 
>> end up finishing the process of whatever they were doing the next day (I 
>> know I've done this several times on various sites), so a timeout of at 
>> least 1 or 2 days is a good default. If you want to come back after the 
>> weekend and carry on, 3 days makes more sense as a minimum.
>>
>> In terms of security, I don't think there is really any need for anyone 
>> to reduce below the default at all (see below). So I'm very unconvinced 
>> about the need for changing to PASSWORD_RESET_TIMEOUT - it is just 
>> unnecessary upgrade work for some existing projects (this is the biggest 
>> consideration for me), and it could encourage people to set the value to 
>> something low that would decrease usability.
>>
>> *Security:*
>>
>> The security of the password reset feature is almost entirely independent 
>> of the value of the timeout setting. There are 3 attack vectors I can see:
>>
>> 1) Someone's email account is compromised, and they then do a password 
>> reset on a Django site.
>>
>> We simply can't protect against this AFAICS.
>>
>> 2) Someone's email account is compromised, and they find/use a password 
>> reset email in the person's inbox.
>>
>> This is the only scenario for which having a shorter timeout makes a 
>> difference. It is somewhat unlikely, because in 99% of cases the attacker 
>> would be able to generate a password reset email themse

Admin raw_id_fields should trigger javascript change event

[Federico Capoano]

Hi everyone,

I have a raw_id_field in the admin and I need to trigger some javascript 
logic when it's value is filled by the user through the popup, but 
unfortunately I found out that when the popup is closed and the value is 
filled into the field the change event is not fired.

I found this quite surprising!

After looking for a solution and digging, I found a workaround which I 
tested and ensured works:
https://groups.google.com/d/msg/django-users/7sIM2-9XirY/d6Yr5_fFBwAJ

I was wondering: why don't we include the change event trigger into django 
itself instead of requiring django users to add this sort of hacks in their 
code?
This is an easy and low risk fix. Is there already an issue for this? I 
volunteer to do this.

Thanks
Federico

-- 
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/5508c560-d186-4b78-bde4-e4807791c291%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - September 30, 2017

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/28624 - Add attribute to let a 
ManyToMany field behave like a list instead of a set (wontfix)

https://code.djangoproject.com/ticket/28587 - All Generic Views are loosing 
args when you pass args and kwargs into urlpattern (invalid)

https://code.djangoproject.com/ticket/28604 - Prevent 
ManifestStaticFilesStorage from leaving behind intermediate files (accepted)

https://code.djangoproject.com/ticket/28613 - Document that 
GenericForeignKey returns None when referring to nonexistent pk (accepted)

https://code.djangoproject.com/ticket/28608 - Allow UserCreationForm and 
UserChangeForm to work with custom user models (accepted)

https://code.djangoproject.com/ticket/28639 - Changing a primary key 
doesn't change corresponding foreign keys (duplicate)

https://code.djangoproject.com/ticket/28623 - Docs: 
 handle_uploaded_file(f) .. what is "f"? (worksforme)

https://code.djangoproject.com/ticket/28585 - Set `has_file_field` context 
attribute for admin change forms conditionally on Form.is_multipart() 
(accepted)

https://code.djangoproject.com/ticket/28598 - BCC addresses are ignored in 
the console and file email backends (accepted)

https://code.djangoproject.com/ticket/28596 - Oracle crashes with id__in 
query with 100k ids (accepted)

https://code.djangoproject.com/ticket/28600 - Add prefetch related support 
to RawQuerySet (accepted)

https://code.djangoproject.com/ticket/28573 - Migrations create a bad index 
if creating and renaming the same foreign key in one migration (duplicate)

https://code.djangoproject.com/ticket/28591 - createsuperuser --username= 
 (blank) should give an error (accepted)

https://code.djangoproject.com/ticket/28644 - Messages not Displaying After 
Redirect (invalid)

https://code.djangoproject.com/ticket/28641 - Improvements to 
QuerySet.bulk_create() (needsinfo)

https://code.djangoproject.com/ticket/28609 - Original request URI is not 
available to development server (wontfix)

https://code.djangoproject.com/ticket/28612 - inspectdb sets max_length to 
-1 if no field length specified in the DB schema (duplicate)

https://code.djangoproject.com/ticket/28619 - Handle ValidationError in 
model saving in admin change views (wontfix)

https://code.djangoproject.com/ticket/28645 - AuthenticationForm's inactive 
user error isn't raised when using ModelBackend (accepted)

https://code.djangoproject.com/ticket/28588 - User.has_perm() with 
superusers hides nonexistent permissions (accepted)

https://code.djangoproject.com/ticket/28614 - FileBasedCache documentation 
shouldn't recommend /var/tmp (wontfix)

https://code.djangoproject.com/ticket/28590 - Quotes around filter string 
omitted in query __str__() (duplicate)

https://code.djangoproject.com/ticket/28589 - When saving in admin, 
readonly fields are potentially overwritten (accepted)

https://code.djangoproject.com/ticket/28618 - Add an easier to make 
templates substitutions raise an exception on error (accepted)

https://code.djangoproject.com/ticket/28621 - Crash in QuerySet.annotate() 
with OuterRef (accepted)

https://code.djangoproject.com/ticket/28653 - Missing ForeignKey.on_delete 
argument in docs (fixed)

https://code.djangoproject.com/ticket/28620 - Loop on boundfields at init 
of inline sub-forms breaks the form set (invalid)

https://code.djangoproject.com/ticket/28655 - Document an example of 
customizing a widget through form.fields (accepted)

https://code.djangoproject.com/ticket/28657 - Strangely odd behaviour when 
ordering QuerySet by BooleanField. (invalid)

Authored

--

https://github.com/brutasse/django-push/pull/24 - Remove support for Django 
< 1.11, add support for Django 2.0

https://github.com/django/django/pull/9170 - Fixed #28654 -- Dropped 
support for SpatiaLite 4.0.
https://github.com/django/django/pull/9171 - Fixed #28584 -- Dropped 
support for SQLite < 3.8.

Reviewed/committed

--

https://github.com/django/django/pull/9015 - Fixed #28562 -- Fixed 
DecimalValidator handling of positive exponent scientific notation.

https://github.com/django/django/pull/9139 - Fixed #28629 -- Made tree.Node 
instances hashable.

https://github.com/django/django/pull/9149 - Completed test coverage for 
default template filters.

-- 
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/900e605f-99f7-4672-bbb9-7d37d45c1bf1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.