Re: Fate of sql* management commands

[Marcin Nowak]

Thanks, I didn't saw it.

But I've found quick ad-hoc solution using monkey patching.
Just include this snippet in project`s __init__:

from django.core.management import sql

def check_for_migrations_bypassed(*args, **kw):
pass

sql.check_for_migrations = check_for_migration_bypassed

(Tested with v1.8)

/BR
Marcin

On Friday, May 29, 2015 at 6:38:11 PM UTC+2, Tim Graham wrote:
>
> There's a ticket waiting someone to implement what has been discussed:
>
> https://code.djangoproject.com/ticket/24481
>
> On Friday, May 29, 2015 at 12:05:48 PM UTC-4, Marcin Nowak wrote:
>>
>>
>>
>> On Monday, March 30, 2015 at 1:58:02 AM UTC+2, Russell Keith-Magee wrote:
>>>
>>>

 *What is the new way to dump the sql schema of currently installed 
 django appz ?* It'd maybe be worth that I provide a doc patch to 
 inform users about it.
 *If there is none, is there an agreement to restore at least sqlall and 
 sqlclear ?*

>>>  
>>> No, there isn't :-)
>>>
>>
>> We need old sql /sqlall behaviour. Currently we can't generate sql for 
>> contrib apps. 
>> Calling `sql auth` raises error:
>>
>> CommandError: App 'auth' has migrations. Only the sqlmigrate and sqlflush 
>> commands can be used when an app has migrations.
>>
>> We're expecting SQL output instead.
>>
>> *We need to bypass migration mechanism for some specific projects*. 
>> Please make life easier but not harder. Django is unusable from v1.7 for 
>> some of us! 
>>
>> Or please give us hint how to achieve old behaviour.
>>
>> /BR
>> Marcin
>>
>

-- 
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/fedc2fb6-e828-4670-bd40-d02f30b859cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fate of sql* management commands

[Tim Graham]

There's a ticket waiting someone to implement what has been discussed:

https://code.djangoproject.com/ticket/24481

On Friday, May 29, 2015 at 12:05:48 PM UTC-4, Marcin Nowak wrote:
>
>
>
> On Monday, March 30, 2015 at 1:58:02 AM UTC+2, Russell Keith-Magee wrote:
>>
>>
>>>
>>> *What is the new way to dump the sql schema of currently installed 
>>> django appz ?* It'd maybe be worth that I provide a doc patch to inform 
>>> users about it.
>>> *If there is none, is there an agreement to restore at least sqlall and 
>>> sqlclear ?*
>>>
>>  
>> No, there isn't :-)
>>
>
> We need old sql /sqlall behaviour. Currently we can't generate sql for 
> contrib apps. 
> Calling `sql auth` raises error:
>
> CommandError: App 'auth' has migrations. Only the sqlmigrate and sqlflush 
> commands can be used when an app has migrations.
>
> We're expecting SQL output instead.
>
> *We need to bypass migration mechanism for some specific projects*. 
> Please make life easier but not harder. Django is unusable from v1.7 for 
> some of us! 
>
> Or please give us hint how to achieve old behaviour.
>
> /BR
> Marcin
>

-- 
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/f889958a-7374-4697-8142-21f440dcf0e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fate of sql* management commands

[Marcin Nowak]

On Monday, March 30, 2015 at 1:58:02 AM UTC+2, Russell Keith-Magee wrote:
>
>
>>
>> *What is the new way to dump the sql schema of currently installed django 
>> appz ?* It'd maybe be worth that I provide a doc patch to inform users 
>> about it.
>> *If there is none, is there an agreement to restore at least sqlall and 
>> sqlclear ?*
>>
>  
> No, there isn't :-)
>

We need old sql /sqlall behaviour. Currently we can't generate sql for 
contrib apps. 
Calling `sql auth` raises error:

CommandError: App 'auth' has migrations. Only the sqlmigrate and sqlflush 
commands can be used when an app has migrations.

We're expecting SQL output instead.

*We need to bypass migration mechanism for some specific projects*. 
Please make life easier but not harder. Django is unusable from v1.7 for 
some of us! 

Or please give us hint how to achieve old behaviour.

/BR
Marcin

-- 
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/429b576a-d951-4e89-b36c-18062b647840%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback #24496 - Check CSRF Referer against CSRF_COOKIE_DOMAIN

[Troy Grosfield]

I just recently posted on the same issue:

   -  https://groups.google.com/forum/#!topic/django-developers/6kUiODYObnU
   
I definitely would like to see some change to make communicating between 
trusted subdomains easier.  In my case it's *https://example.com* posting 
data to *https://api.example.com* which currently fails csrf referer 
validation when using a secure (https) site.

*My thoughts on the proposed fix:*

I don't have any issues with validating against the CSRF_COOKIE_DOMAIN.  I 
would like to say I'll always own my subdomains, but who knows, that could 
change in the future and that may not be everyone else's same opinion.  I 
have worked with other companies that subdomains were passed off to 
different organizations within the company so all sites technically didn't 
have the same owner.  Yes, we should trust other orgs in our same company, 
but the point is, the root owner of *https://example.com* was not in fact 
the owner of all subdomains.  In this case, I wouldn't want 
CSRF_COOKIE_DOMAIN checking, but instead a more explicit approach (see 
below).

The other thought here would be to add an additional setting that more be 
explicit than *CSRF_COOKIE_DOMAIN*.  Instead, add a new setting, something 
like *CSRF_WHITELIST_ORIGINS,*  that explicitly calls out which origins are 
legit.  This would handle the case better than the "one-size-fits-all" 
CSRF_COOKIE_DOMAIN matching.  Inside CSRF_WHITELIST_ORIGINS you can define 
wildcards if you'd like to do the same thing as the proposed change 
, bit it's more explicit on 
your intentions for the behavior that you'd expect. 

*Match all subdomains example:*

CSRF_WHITELIST_ORIGINS = ['*.example.com']

OR

CSRF_WHITELIST_ORIGINS = ['.example.com']

*More explicit whitelisting:*

CSRF_WHITELIST_ORIGINS =[
'api.example.com',
'developers.example.com'
]

Security should always more explicit than implicit IMHO, but just to be 
clear, I am in big favor of a change as I need if for my sites and there 
are too many hacky solutions [1][2][3][4] that currently get around this by 
manually changing the *request.META['HTTP_REFERER']*.  Eeeek!

Troy

[1] 
https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py#L26
[2] https://groups.google.com/d/msg/django-developers/6kUiODYObnU/1wqxBqFP8UQJ
[3] http://zachsnow.com/#!/blog/2012/django-subdomains-csrf-and-https/
[4] http://bash-shell.net/blog/2014/aug/16/django-cors-and-csrf-validation/

On Thursday, March 19, 2015 at 10:50:05 AM UTC-6, Matt Robenolt wrote:
>
> Ticket and patch have been submitted regarding this:
>
> https://code.djangoproject.com/ticket/24496
> https://github.com/django/django/pull/4337
>
> Since this is related to CSRF and technically weakening the strictness of 
> the Referer check, Tim Graham suggested soliciting feedback here to get 
> more eyeballs and feedback.
>
> Please let me know if there's more context needed that can be added to the 
> ticket.
>
> My tl;dr is that Django should allow a Referer match across a subdomain, 
> and not exactly matching `request.get_host()` since cookies are allowed to 
> be set on subdomains as well. This is similar in vain to ALLOWED_HOSTS, 
> except Django would purely validate against the CSRF_COOKIE_DOMAIN.
>
> Thanks. <3
>

-- 
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/c14fdc37-f8cb-4722-8a6b-d4dc3806713f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with CsrfViewMiddleware and "referer" checking for trusted and secure subdomains

[Troy Grosfield]

This same issue is being discussed here as well:

   - https://groups.google.com/forum/#!topic/django-developers/tEEw02RhV0M
   


On Friday, May 29, 2015 at 8:23:43 AM UTC-6, Troy Grosfield wrote:
>
> Thanks @andre for the idea.  I have seen the stuff from 
> django-cors-headers and use that app in my app.  However, I can't help, but 
> feel like changing the *request.MEA['HTTP_REFERER']* feels way to hacky 
> for my liking. I know this would work as a workaround until the ticket that 
> @ramiromorales pointed it is completed (thanks @ramiromorales for pointing 
> that out):
>
>- https://github.com/django/django/pull/4337
>
> Would be happy to help with that ticket where possible!  Good to see it's 
> getting resolved!
>
> Troy
>
> On Friday, May 29, 2015 at 4:11:24 AM UTC-6, Ramiro Morales wrote:
>>
>> On Fri, May 29, 2015 at 12:41 AM, Troy Grosfield 
>>  wrote: 
>> > 
>> > I have the following domain and subdomains both are trusted and both 
>> are secure (https): 
>> > 
>> > https://example.com 
>> > https://api.example.com 
>> > 
>> > When making POST ajax request from https://example.com to 
>> https://api.example.com I see the following error message: 
>> > 
>> > detail: "CSRF Failed: Referer checking failed - 
>> https://example.com/path/to/some/url does not match 
>> https://api.example.com/.; 
>> > 
>> > 
>> > Which takes me to the CsrfViewMiddleware where I see same_origin 
>> checking: 
>> > 
>> > # Note that request.get_host() includes the port. 
>> > good_referer = 'https://%s/' % request.get_host() 
>> > if not same_origin(referer, good_referer): 
>> > reason = REASON_BAD_REFERER % (referer, good_referer) 
>> > return self._reject(request, reason) 
>> > 
>> > I trust my subdomain, but there's no way for this code to actually pass 
>> this validation.  Am I just missing something?  Why would trusted 
>> subdomains fail validation here?  Can't this at least be a setting 
>> something like TRUSTED_SUBDOMAINS that's also checked? 
>>
>> See ticket [1]24496, it's associated [2]PR and e.g. thios [3]comment. 
>>
>> Any help in advancing the issue (e.g. reviewing the patch and adding 
>> the missing documentation changes) is welcome. 
>>
>>
>> 1. https://code.djangoproject.com/ticket/24496 
>> 2. https://github.com/django/django/pull/4337/files 
>> 3. https://code.djangoproject.com/ticket/16010#comment:3 
>>
>> -- 
>> Ramiro Morales 
>> @ramiromorales 
>>
>

-- 
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/1738c002-5902-4513-a740-172efddfdf45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with CsrfViewMiddleware and "referer" checking for trusted and secure subdomains

[Troy Grosfield]

Thanks @andre for the idea.  I have seen the stuff from django-cors-headers 
and use that app in my app.  However, I can't help, but feel like changing 
the *request.MEA['HTTP_REFERER']* feels way to hacky for my liking. I know 
this would work as a workaround until the ticket that @ramiromorales 
pointed it is completed (thanks @ramiromorales for pointing that out):

   - https://github.com/django/django/pull/4337
   
Would be happy to help with that ticket where possible!  Good to see it's 
getting resolved!

Troy

On Friday, May 29, 2015 at 4:11:24 AM UTC-6, Ramiro Morales wrote:
>
> On Fri, May 29, 2015 at 12:41 AM, Troy Grosfield 
>  wrote: 
> > 
> > I have the following domain and subdomains both are trusted and both are 
> secure (https): 
> > 
> > https://example.com 
> > https://api.example.com 
> > 
> > When making POST ajax request from https://example.com to 
> https://api.example.com I see the following error message: 
> > 
> > detail: "CSRF Failed: Referer checking failed - 
> https://example.com/path/to/some/url does not match 
> https://api.example.com/.; 
> > 
> > 
> > Which takes me to the CsrfViewMiddleware where I see same_origin 
> checking: 
> > 
> > # Note that request.get_host() includes the port. 
> > good_referer = 'https://%s/' % request.get_host() 
> > if not same_origin(referer, good_referer): 
> > reason = REASON_BAD_REFERER % (referer, good_referer) 
> > return self._reject(request, reason) 
> > 
> > I trust my subdomain, but there's no way for this code to actually pass 
> this validation.  Am I just missing something?  Why would trusted 
> subdomains fail validation here?  Can't this at least be a setting 
> something like TRUSTED_SUBDOMAINS that's also checked? 
>
> See ticket [1]24496, it's associated [2]PR and e.g. thios [3]comment. 
>
> Any help in advancing the issue (e.g. reviewing the patch and adding 
> the missing documentation changes) is welcome. 
>
>
> 1. https://code.djangoproject.com/ticket/24496 
> 2. https://github.com/django/django/pull/4337/files 
> 3. https://code.djangoproject.com/ticket/16010#comment:3 
>
> -- 
> Ramiro Morales 
> @ramiromorales 
>

-- 
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/739a0c21-5ce7-452b-9a89-8b1c5cd35e34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL namespaces

[Marten Kenbeek]

>
> I think it's an unlikely case anyway, but out of curiosity what are the 
> workarounds?


In the case of a 2-tuple, just pass (admin.site.urls[0], 'dashboard'). In 
the case of a module, you'll have to directly import the module and pass a 
(patterns, app_name) tuple. 

If an app has templates and view code that are reversing 
> :, then changing the app name (e.g. by an undocumented 
> feature, passing a (patterns, app_name) tuple), then all those URLs will 
> break. Unless I'm missing something, an app *must always* be installed with 
> the app name that is hard coded in its templates and view code, so there is 
> no workaround for app namespace conflicts?
>
 

Does or would it work to allow two apps with the same app namespace, as 
> long as they both are installed with customised instance names, so that the 
> "default app" namespace lookup doesn't return anything, and Django must 
> fallback to the `current_app` to determine which app is being reversed?


 An app doesn't necessarily have to use its own patterns. With that said, 
it's up to the user to make sure it works if they are to mess with the 
app_name. Two conflicting apps can be installed with different namespaces, 
but there will always be a default (the last one, if there is no namespace 
with the same name). With a consistent use of `current_app` (even if it's 
not the *current* application used in the request), you can avoid problems. 

If possible, I'd like to add `current_app` to the request by default, but 
that has been attempted before, and backwards compatibility is a problem. 
That would allow an app to more reliably reverse its own urls, provided 
that their code and templates are called from within their own application. 

I'd rather see the "app name, period" (as opposed to a default app name) 
> defined as a variable in an app's URLconf as per #11642 or as an attribute 
> of the `urlpatterns` object, that Django looks at when a URLconf is 
> included with a dotted path string, instead of requiring users to import 
> and then include a `(patterns, app_name)` tuple. Basically, the app name 
> defined by the app should be used for both of:
>
 

include(r^foo/', 'foo.urls')
>
 

and
>
 

from foo.urls import some_tuple
> include(r'^foo/', some_tuple),


I also prefer the first option. That would be the "main" way of setting the 
app_name. The second option exists for things like `admin.site.urls`, which 
historically have always returned a tuple, instead of an object with an 
`urlpatterns` attribute. If objects like `admin.site` would have 
`urlpatterns` and `app_name` attributes/properties, this could be 
deprecated in favour of a single way to provide an app_name. Not sure if 
this is desirable, but it's an option. 

Not exactly related to the issue at hand, but if we are reworking URL 
> namespaces it might be worth some consideration. One reason why I always 
> avoid using URL namespaces these days is that it becomes impossible to 
> override an app URL at the project level. Project authors are stuck with 
> the exact URLs defined by the app author, all located below the same root 
> path where the URLs are included and with the same view behaviour.
>
 

Without namespaced URLs, the project author can include their own version 
> of a URL at any location (as long as it comes before the app's included 
> URLs) and change the view behaviour. For namespaced URLs, I'd like to be 
> able to do something like:
>
 

urlpatterns = patterns('',
> url(r'^my_foo_login/$', 'myapp.views.my_foo_login', name='login', 
> app='foo', namespace='foo'),
> url(r'^foo/', include('foo.urls', app='foo', namespace='foo')),
> )
>
 

Then when templates or view code in the `foo` app does reverse('foo:login') 
> they will get `/my_foo_login/` instead of `/foo/login/` and I can change 
> the behaviour of the view.


Now that's something I hadn't thought about. I don't believe there is an 
easy solution, at least not with the current API, so this will probably 
have to wait for the new API. I'll make sure to think this through, and 
find a way to handle this before I start working on the final 
implementation. 

Marten

Op vrijdag 29 mei 2015 02:52:24 UTC+2 schreef Tai Lee:
>
> Thanks for taking the time to write up this proposal. I agree on pretty 
> much all counts, but I do have a few comments:
>
> 1)
>
> If an app has templates and view code that are reversing 
> :, then changing the app name (e.g. by an undocumented 
> feature, passing a (patterns, app_name) tuple), then all those URLs will 
> break. Unless I'm missing something, an app *must always* be installed with 
> the app name that is hard coded in its templates and view code, so there is 
> no workaround for app namespace conflicts?
>
> Does or would it work to allow two apps with the same app namespace, as 
> long as they both are installed with customised instance names, so that the 
> "default app" namespace lookup doesn't return anything, and Django must 
> fallback to the 

Re: Fellow Report - April 24, 2015

[Tim Graham]

It seems you are correct. I reopened the ticket and left a comment with the 
result of my investigation.

On Thursday, May 28, 2015 at 10:36:09 PM UTC-4, Chris Moirano wrote:
>
> Hey Tim,
>
> Sorry if this may be an unnecessary question but the ticket 24704 
> (Development server does not restart on syntax errors) seems to be a 
> regression and not a fix. I was previously on version 1.6.x and the 
> development server would continue to run if there were syntax errors. The 
> only change with this ticket was the docs were updated to remove the line 
> "but it won't stop the server"(commit 
> )
>  
> from the docs.  Is this development server change intentional in 1.8? 
>
> On Saturday, April 25, 2015 at 7:09:27 PM UTC-5, Tim Graham wrote:
>>
>> I am thinking that if all goes well, we will probably release a 1.8.1 bug 
>> fix release by next Friday. Currently we have about 20 fixes for that 
>> release.
>>
>> Report for week ending April 24, 2015:
>>
>> Triaged
>>
>> ---
>>
>> https://code.djangoproject.com/ticket/24668 - Update docs example code 
>> for ModelAdmin.save_formset() (fixed)
>>
>> https://code.djangoproject.com/ticket/24676 - Regression on ManytoMany 
>> representation in the admin interface (accepted)
>>
>> https://code.djangoproject.com/ticket/24675 - Skip "SET SQL_AUTO_IS_NULL 
>> = 0" on versions of MySQL that don't need it (accepted)
>>
>> https://code.djangoproject.com/ticket/24630 - Misleading/incorrect docs 
>> about RunPython and transactions (accepted)
>>
>> https://code.djangoproject.com/ticket/24686 - Support for Moving a model 
>> between two Django apps (accepted)
>>
>> https://code.djangoproject.com/ticket/24690 - ArrayField data bleeds 
>> between instances when using field.append(item) (accepted)
>>
>> https://code.djangoproject.com/ticket/24689 - DetailView & ListView 
>> get_template_name and get_context_object_name fail with deferred QuerySet 
>> (accepted)
>>
>> https://code.djangoproject.com/ticket/24691 - Document 
>> model._state.adding (since UUIDField sets value before save) (accepted)
>>
>> https://code.djangoproject.com/ticket/24698 - Relation clear fails 
>> silently when using OneToOneField+UUIDField (accepted)
>>
>> https://code.djangoproject.com/ticket/24704 - Development server does 
>> not restart on SynaxError (fixed)
>>
>> Authored
>>
>> 
>>
>> https://github.com/django/djangoproject.com/pull/458 - Fixed #445 -- 
>> Fixed NotADirectory exception in docs app.
>>
>> https://github.com/django/django/pull/4389 - Fixed #24526 -- Combined 
>> django.request/security loggers with the root logger.
>>
>> https://github.com/django/django/pull/4548 - Fixed #24649 -- Allowed 
>> using Avg aggregate on non-numeric field types.
>>
>> Reviewed/committed
>>
>> --
>>
>> https://github.com/django/django/pull/4534 - Refactored 
>> PasswordResetTokenGenerator to be a bit more extensible.
>>
>> https://github.com/django/django/pull/4458 - Refs #24397 -- Sped up 
>> model reloading in ProjectState.
>>
>> https://github.com/django/django/pull/4393 - Fixed #22394 -- Refactored 
>> built-in datetime lookups to transforms.
>>
>> https://github.com/django/django/pull/4533 - Refs #24591 -- Optimized 
>> cloning of ModelState objects.
>>
>> https://github.com/django/django/pull/4460 - Fixed #24591 -- Optimized 
>> cloning of ModelState objects.
>>
>> https://github.com/django/django/pull/4539 - Fixed #24613 -- Added 
>> example to QuerySet.defer() documentation
>>
>> https://github.com/django/django/pull/4512 - Fixed #24643 -- Added 
>> get_context_data() method to FormMixin
>>
>> https://github.com/django/django/pull/4546 - Fixed #24689 -- Fixed 
>> DetailView methods with deferred QuerySet
>>
>> Reviews of core dev work
>>
>> 
>>
>> https://github.com/django/django/pull/4447 - Fixed #24573 -- Considered 
>> new related models for reloading
>>
>> https://github.com/django/django/pull/4529 - Fixed #24654 -- Based 
>> ordering circular references detection on columns.
>>
>> https://github.com/django/django/pull/4416 - Fixed #22598 -- Allowed 
>> make_aware to work with ambiguous datetime
>>
>> https://github.com/django/django/pull/4558 - Fixed #24701 -- Converted 
>> model manager names to unicode in migrations
>> https://github.com/django/django/pull/4555 - Added lazyness to 
>> contrib.gis imports
>>
>
> Confidentiality Notice: This message and any files transmitted with it are 
> confidential and intended solely for the use of the individual or entity to 
> whom they are addressed. If you are not the intended recipient, you are 
> hereby notified that review, disclosure, dissemination, distribution, or 
> copying of it or its contents is prohibited. If you have received this 
> message in error, please notify the sender immediately and permanently 
> delete this message and any attachments.
>

-- 
You received this message because you are subscribed to 

Re: Issue with CsrfViewMiddleware and "referer" checking for trusted and secure subdomains

[Ramiro Morales]

On Fri, May 29, 2015 at 12:41 AM, Troy Grosfield
 wrote:
>
> I have the following domain and subdomains both are trusted and both are 
> secure (https):
>
> https://example.com
> https://api.example.com
>
> When making POST ajax request from https://example.com to 
> https://api.example.com I see the following error message:
>
> detail: "CSRF Failed: Referer checking failed - 
> https://example.com/path/to/some/url does not match https://api.example.com/.;
>
>
> Which takes me to the CsrfViewMiddleware where I see same_origin checking:
>
> # Note that request.get_host() includes the port.
> good_referer = 'https://%s/' % request.get_host()
> if not same_origin(referer, good_referer):
> reason = REASON_BAD_REFERER % (referer, good_referer)
> return self._reject(request, reason)
>
> I trust my subdomain, but there's no way for this code to actually pass this 
> validation.  Am I just missing something?  Why would trusted subdomains fail 
> validation here?  Can't this at least be a setting something like 
> TRUSTED_SUBDOMAINS that's also checked?

See ticket [1]24496, it's associated [2]PR and e.g. thios [3]comment.

Any help in advancing the issue (e.g. reviewing the patch and adding
the missing documentation changes) is welcome.


1. https://code.djangoproject.com/ticket/24496
2. https://github.com/django/django/pull/4337/files
3. https://code.djangoproject.com/ticket/16010#comment:3

-- 
Ramiro Morales
@ramiromorales

-- 
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/CAO7PdF-WiQN_6FP0uW6P3%3D1bbQFtDy_FBRpYayxpKMByVVh-oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with CsrfViewMiddleware and "referer" checking for trusted and secure subdomains

[André Tavares]

Hey,

I also came across this "issue" which I believe will become very common as 
architectures as the one described above are starting to be more common. 
Moreover, IMHO the overall way that Django handles CORS issues is 
sub-optimal... another issue that I keep bumping against is having multiple 
"Access-Control-Allow-Origin".

For the case described in this thread, I ended up adding the following code 
bellow to the "dispatch" of my custom API View that all API Handlers 
extend, before and after CSRF validation to ensure that, when CRSF checking 
is happening, things are as Django expects so that it doesn't break as you 
described.

@staticmethod
def _https_referer_replace(request):
"""
When https is enabled, django CSRF checking includes referer checking
which breaks when using CORS. This function updates the HTTP_REFERER
header to make sure it matches HTTP_HOST, provided that our cors logic
succeeds.

Based on snippet taken from:

https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py
"""
if settings.YAPI.get('XS_SHARING_REPLACE_HTTPS_REFERER') is True:
origin = request.META.get('HTTP_ORIGIN')
allowed_origins = settings.YAPI['XS_SHARING_ALLOWED_ORIGINS']
if request.is_secure() and origin and 'ORIGINAL_HTTP_REFERER' not in 
request.META:
if allowed_origins != '*' and origin not in allowed_origins:
return
try:
http_referer = request.META['HTTP_REFERER']
http_host = "https://%s/; % request.META['HTTP_HOST']
request.META = request.META.copy()
request.META['ORIGINAL_HTTP_REFERER'] = http_referer
request.META['HTTP_REFERER'] = http_host
except KeyError:
pass

@staticmethod
def _https_referer_replace_reverse(request):
"""
Put the HTTP_REFERER back to its original value and delete the temporary 
storage.

Based on snippet taken from:

https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py
"""
if settings.YAPI.get('XS_SHARING_REPLACE_HTTPS_REFERER') is True and 
'ORIGINAL_HTTP_REFERER' in request.META:
http_referer = request.META['ORIGINAL_HTTP_REFERER']
request.META['HTTP_REFERER'] = http_referer
del request.META['ORIGINAL_HTTP_REFERER']




On Friday, 29 May 2015 06:33:12 UTC+1, Troy Grosfield wrote:
>
> Don't want to do csrf_exempt because I need csrf protection since I'm 
> posting data to the api. This works in cases where the site isn't secure 
> (https), but once the code is moved to prod (secure site) it fails.
>
>
> On Thursday, May 28, 2015 at 11:09:04 PM UTC-6, Josh Smeaton wrote:
>>
>> Forgive me, but wouldn't you just declare those views as csrf_exempt? A 
>> csrf token at one site isn't going to be valid at another, right?
>>
>> On Friday, 29 May 2015 13:44:42 UTC+10, Troy Grosfield wrote:
>>>
>>> I have the following domain and subdomains both are trusted and both are 
>>> secure (https):
>>>
>>>- https://example.com
>>>- https://api.example.com
>>>
>>> When making POST ajax request from *https://example.com 
>>> * to *https://api.example.com 
>>> * I see the following error message:
>>>
>>>
>>>1. detail: "CSRF Failed: Referer checking failed - 
>>>https://example.com/path/to/some/url does not match 
>>>https://api.example.com/.;
>>>
>>>
>>> Which takes me to the *CsrfViewMiddleware* where I see *same_origin* 
>>> checking:
>>>
>>> # Note that request.get_host() includes the port.
>>> good_referer = 'https://%s/' % request.get_host()
>>> if not same_origin(referer, good_referer):
>>> reason = REASON_BAD_REFERER % (referer, good_referer)
>>> return self._reject(request, reason)
>>>
>>> I trust my subdomain, but there's no way for this code to actually pass 
>>> this validation.  Am I just missing something?  Why would trusted 
>>> subdomains fail validation here?  Can't this at least be a setting 
>>> something like *TRUSTED_SUBDOMAINS* that's also checked?
>>>
>>> The other option I see here it to override the *CsrfViewMiddleware's* 
>>> *process_view* method as others have done 
>>> . 
>>>   However, it ends up being a rather extensive rewrite for only the few 
>>> lines, that are mentioned above, that need to change.  Can we rewrite the 
>>> *CsrfViewMiddleware 
>>> *to be more modular so it's easy to subclass and overwrite pieces of 
>>> the csrf vallidation?  Something along the lines of:
>>>
>>> class CsrfViewMiddleware(object):
>>>
>>> def process_view(self, request, callback, callback_args, 
>>> callback_kwargs):
>>>
>>> [...]
>>> 
>>> # Assume that anything not defined as 'safe' by RFC2616 needs 
>>> protection
>>> if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
>>> [...]