It seems that the issue is somehow related to empty trac_session cookie which
somehow has got set. Here is the curl request which can be used to obtain the
403 response:
curl -I -H 'Cookie: trac_session=' https://code.djangoproject.com/ticket/2659
Clearing the cookies solved the problem, so
Trying to browse any ticket on code.djangoproject.com yields 403 Forbidden,
with a message “TICKET_VIEW privileges are required to perform this operation.
You don't have the required permissions.”. An attempt to login via
https://code.djangoproject.com/login results in 502. It has been broken
If this problem has been reported before, I don't remember it. Nothing
about our Trac installation has changed recently that I'm aware of. In case
it helps, I just updated to Trac 1.0.11.
It's unclear if the problem would be our problem and or an issue with Trac
but for what it's worth, our
Let me start saying sorry if this actually belongs to django-users rather
than developers.
I'm curious about (and if someone can point me to the code) how exactly
django handles database connections (in particular when persistent
connections are used). As I can tell from the docs, they are
Here's a ticket requesting the documentation you seek (as far as I
understand):
https://code.djangoproject.com/ticket/20562
On Wednesday, June 1, 2016 at 6:34:05 PM UTC-4, Cristiano Coelho wrote:
>
> Let me start saying sorry if this actually belongs to django-users rather
> than developers.
>
That's pretty close but on a much more difficult level, since it is about
multi processing? Things starts to get very odd with multi processing and
django, compared to threads that you can easily launch a new thread or pool
without any special work, it is just the database connections handling
Yes, mainly some things that needs to be done async and you don't want to
keep up the request for those such as email sending or logging. So this
work is just offloaded to a thread pool and the request returns instantly.
Also when you are using auto scaling services from amazon and since each
Hi all,
I would like to know if is there any reason why currently there is no
option to define default placeholder configuration (i.e. such as "default"
item in CMS_LANGUAGES setting). In my opinion it would be really helpful
for example to change the default language_fallback behaviour which
Hi Michal,
Do you mean something like what is being discussed
at https://github.com/divio/django-cms/pull/5006?
Jonas
On Wednesday, June 1, 2016 at 6:25:48 PM UTC+9, Michał Lechman wrote:
>
> Hi all,
>
> I would like to know if is there any reason why currently there is no
> option to define
Exactly. Sorry but I haven't found it before.
--
Michal
W dniu środa, 1 czerwca 2016 11:31:02 UTC+2 użytkownik Jonas Obrist napisał:
>
> Hi Michal,
>
> Do you mean something like what is being discussed at
> https://github.com/divio/django-cms/pull/5006?
>
> Jonas
>
> On Wednesday, June 1, 2016
10 matches
Mail list logo
