Right now what django is doing is :-
1. It checks the session id is correct or not by checking the user
associated with the session id
2. If the session id is not present it send the user as anonomous and
because of which it redirects one to the login page .
3. But my concern is that if i want t
Right now what django is doing is :-
1. It checks the session id is correct or not by checking the user
associated with the session id
2. If the session id is not present it send the user as anonomous and
because of which it redirects one to the login page .
3. But my concern is that if i want t
hi
what i can understand now is while you are running your application on a
browser based VPN the problem is the browser accumulates a session id after
you logout first time because of session id and when you login back again
there is a session conflict and the user is automaticlly logged out!
Thank you Russ. I'll reconsider expressing my full thoughts on Channels
more likely in another thread. For now I do think it's worth addressing
this issue of benchmarks/performance which keeps being brought up. The
argument is that since this is optional we don't need to see the benchmarks
beca
Hi Tim,
I think we should favor displaying a message in accordance with the setting
the user is using as it will make the transition less confusing. In the
case of the documented check message I think using the form
"MIDDLEWARE/MIDDLEWARE_CLASSES" would make it easier to read then
mentioning t
Hi Mark,
On Thu, May 5, 2016 at 8:41 AM, Mark Lavin wrote:
> Major features have never been perfect, no, but they have in the past
> typically gone through two paths to prove out their design/API/usefulness.
> One is as an established and mature third-party app such as messages,
> staticfiles, a
On Wed, May 4, 2016 at 6:12 PM, Tim Graham wrote:
> The future is hard to predict, but I'll add that I'm a tad nervous about
> this as well.
>
> I'm completely inexperienced with channels at this time. Who else has a
> good grasp of the code right now and could help fix release blocking bugs
> if
The future is hard to predict, but I'll add that I'm a tad nervous about
this as well.
I'm completely inexperienced with channels at this time. Who else has a
good grasp of the code right now and could help fix release blocking bugs
if Andrew isn't available? Are we playing for any or all bug f
Major features have never been perfect, no, but they have in the past
typically gone through two paths to prove out their design/API/usefulness.
One is as an established and mature third-party app such as messages,
staticfiles, and django-secure. More recently the other has been through
the DEP
I've been working on this and wanted to raise a couple points for
discussion.
How should we treat error messages in place like system checks where we
have phrases like "Edit your MIDDLEWARE_CLASSES" ... of course the check
can easily check both MIDDLEWARE and MIDDLEWARE_CLASSES without much eff
Hi Rich, django-users is the appropriate place to ask "is it a bug?" type
questions. We try not to use this mailing list as a second level support
channel, otherwise it'd get really noisy. Thanks for understanding.
By the way, Django 1.7 is no longer supported. Please make sure you can
reproduc
I'm in the middle of trying to track down a problem with loading fixtures
during unit tests -- I'm hesitant to call it a bug in Django 1.7, but the
inconsistent behavior is really stumping me.
Essentially I've made a fixture via
manage dumpdata --indent=3 -e sessions -e admin -e contenttype
Hi,
We use it here for a similar use case (small NGO's project management
database) and are very happy. It's almost exclusively based on django-admin
to keep everything as modular and easy to maintain as possible, which means
our forms can't be too complex and do reflect the database schema (1 for
On Wed, May 4, 2016 at 2:45 PM, Marc Tamlyn wrote:
> Major features merged into Django have generally never been as "perfect"
> as the standards required for smaller patches. There's a recognisation of
> the need for ongoing work, probably over the course of multiple versions,
> in order to perfe
Major features merged into Django have generally never been as "perfect" as
the standards required for smaller patches. There's a recognisation of the
need for ongoing work, probably over the course of multiple versions, in
order to perfect any major new feature. The effort involved in getting a
pa
Hi everyone,
We finally have everything in place to pay people from the MOSS funds given
to us by Mozilla for Channels (and more importantly we now have the money
itself), so now I'd like to open the call for help.
We have a list of tasks that need doing in Channels, and the money to pay
people f
On Wed, May 4, 2016 at 12:28 PM, Mark Lavin wrote:
> I can (and do) appreciate the effort that's gone into this work while
> still feeling as though it isn't ready to be merged with Django. To be
> honest given that this PR contains almost no changes to Django itself and
> only adds new code, I d
I can (and do) appreciate the effort that's gone into this work while still
feeling as though it isn't ready to be merged with Django. To be honest
given that this PR contains almost no changes to Django itself and only
adds new code, I don't understand why it can't live outside of Django while
I like Markus' suggestion and I think that's in line with how Django
handles other optional dependencies such as the db bindings
(psycopg2, MySQLdb, etc). Those raise an ImproperlyConfigured exception
when there is an import error. The memcache cache backend on the other hand
raises an import e
On Wed, May 4, 2016 at 11:52 AM, Mark Lavin wrote:
>
>
> Given that there is no guarantee of message delivery, I don't think this
> is suitable or recommended for using for background tasks. I don't think
> the Django docs should encourage that usage. At least without a strong
> warning that this
On Wednesday, May 4, 2016 at 12:39:02 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Wed, May 4, 2016 at 8:26 AM, Mark Lavin > wrote:
>
>> As noted in the PR there is at least one new setting,
>> CHANNEL_SESSION_ENGINE, which is lacking documentation.
>>
>
> That's been added now.
>
>
>> The notes
On Wed, May 4, 2016 at 10:06 AM, Markus Holtermann wrote:
> What about having asgiref and daphne as optional dependencies instead of
> hard once and raising a proper exception "please install ..." when the
> import fails?
>
> ```
> try:
>from asgiref import ...
> except ImportError:
>rais
What about having asgiref and daphne as optional dependencies instead of
hard once and raising a proper exception "please install ..." when the
import fails?
```
try:
from asgiref import ...
except ImportError:
raise ImportError(
"Please ensure you installed asgiref to use this featu
On Wed, May 4, 2016 at 8:26 AM, Mark Lavin wrote:
> As noted in the PR there is at least one new setting,
> CHANNEL_SESSION_ENGINE, which is lacking documentation.
>
That's been added now.
> The notes on deployment for "Running ASGI under WSGI" don't give any
> motivation why you would want to
As noted in the PR there is at least one new setting,
CHANNEL_SESSION_ENGINE, which is lacking documentation. The notes on
deployment for "Running ASGI under WSGI" don't give any motivation why you
would want to do this given that it doesn't support websockets in this
case. Is there any advanta
I don't recall any similar reports. Anyway, "is it a bug?" questions go to
django-users. You'll need to include steps to reproduce the issue in order
to get help.
On Wednesday, May 4, 2016 at 7:29:52 AM UTC-4, Samarjeet Singh wrote:
>
> the problem is on the flush function of django 1.8 and beca
On Wed, May 4, 2016 at 6:15 AM, Mark Lavin wrote:
> I had assumed this was still a work in progress because there are missing
> tests and some documentation. The build is passing but the unittest
> coverage for the new modules seems low or at least not up to the standards
> I expect for Django co
I had assumed this was still a work in progress because there are missing
tests and some documentation. The build is passing but the unittest
coverage for the new modules seems low or at least not up to the standards
I expect for Django contributions. The same for the daphne and asgiref
package
Thanks for the info, and for the quick fix!
Jacob
On Wed, May 4, 2016 at 3:48 AM, Florian Apolloner
wrote:
> Hi,
>
> earlier today (roughly 9:30 UTC) I deployed a wrong (local) branch from
> our ansible repository to dp.com. This branch included our old (now
> expired) gandi SSL certificate. On
i think this is a development issue because of request.session.flush if i
logout all the session detail is deleted and not modified because of which
next time when we login there is a session conflict so i dont know if it
ths problem is with everyone or only i am facing it .
Please help!!
On T
the problem is on the flush function of django 1.8 and because of which the
session is deleted instead of modifying and then a new session is created
at logout and which gets conflicted with the new user session so that is
why i am not able to log in .so is this problem with me only or others al
A post-mortem is at
https://groups.google.com/forum/#!topic/django-developers/7qzh2n3ZDRc
Cheers,
/Markus
On Wednesday, May 4, 2016 at 11:51:08 AM UTC+2, Marc Tamlyn wrote:
>
> We are aware of the issue and are working on it.
>
> Thanks,
> Marc
>
> On 4 May 2016 at 10:30, Wim Feijen >
> wrote:
Hi,
earlier today (roughly 9:30 UTC) I deployed a wrong (local) branch from our
ansible repository to dp.com. This branch included our old (now expired)
gandi SSL certificate. Once I realized what I did (which took a few minutes
since I was preparing to push a commit) I switched to the proper b
We are aware of the issue and are working on it.
Thanks,
Marc
On 4 May 2016 at 10:30, Wim Feijen wrote:
> Hi guys,
>
> Apologies if I am posting in the wrong group, but the certificate of
> djangoproject.com expired today (4 May).
>
> Wim
>
> --
> You received this message because you are subsc
Hi guys,
Apologies if I am posting in the wrong group, but the certificate of
djangoproject.com expired today (4 May).
Wim
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group a
35 matches
Mail list logo