On Thu, May 17, Jacob Kaplan-Moss wrote:
> On 5/15/07, jedie <[EMAIL PROTECTED]> wrote:
> > Whats about INTERNAL_IPS [1] ?
>
> I think you need to let this one go. Malcom's already given a -1 and
> no other developers stepped up with even a +0.
Malcolm only gave it -1 for a very specific reason,
On 5/15/07, jedie <[EMAIL PROTECTED]> wrote:
> Whats about INTERNAL_IPS [1] ?
I think you need to let this one go. Malcom's already given a -1 and
no other developers stepped up with even a +0.
I'd love to see you develop this as an add-on -- a piece of exception
middleware, probably -- but I do
Whats about INTERNAL_IPS [1] ?
The special debugger is only available if...
...settings.DEBUG is ON (or a seperate Variable)
and
...the request IP is in INTERNAL_IPS
[1] http://www.djangoproject.com/documentation/settings/#internal-ips
--~--~-~--~~~---~--~~
You
Hoi,
A possible solution would be moving the debug view from the core into
a middleware. Then it's possible to replace the middleware and move
the debugger into a contrib package.
Regards,
Armin
--~--~-~--~~~---~--~~
You received this message because you are sub
And that other setting, even to True, won't be used if debug is to
False (to prevent oblivions) ?
Moreover, to stop lambda users from accessing this debugger, maybe we
could enforce the admin to type a password in the console before
proposing its completes features ?
I mean, you have the debug te
My preference would be to have it as either a package in contrib, or a
third party package that users can install. I don't know how easy it
would be to override Django's default debug handler but shouldn't be
too hard. This way we don't have any on-by-default situations, and it
should be fairly sa
On 4/16/07, Baptiste <[EMAIL PROTECTED]> wrote:
>
> Maybe some people use the development server in production... and
> maybe some people don't use it in devel !
> Precarious to take that for reference, don't you think ?
True. Tying the special debugger to the development server leaves people
wh
On 4/16/07, Armin Ronacher <[EMAIL PROTECTED]> wrote:
>
>
> Hoi,
>
> -1 for the database interaction. The debugger should also work if the
> database is fucked up.
Mind the language, please. This is a formal mailing list discussing serious
issues. Keeping the language civil is just one way we ens
Maybe some people use the development server in production... and
maybe some people don't use it in devel !
Precarious to take that for reference, don't you think ?
On 16 avr, 01:45, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> Sounds complicated, and I don't think it's necessary. Malcolm's conce
Hoi,
-1 for the database interaction. The debugger should also work if the
database is fucked up.
Regards,
Armin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
Sounds complicated, and I don't think it's necessary. Malcolm's concern was
that this special debugger never be enabled in production. What user is
associated with a request really has nothing to do with whether the code is
running in production -- in order to test out changes in my app before th
Hum, yeah, so maybe we could add a permission that could be set to a
lambda user and that would allow the access to this debugger. It
wouldn't care if the account is disabled or not, so that could
simulate an unauthenticated user (if the app checks
user.is_authenticated() and user.is_active). I kn
But don't you want to be able to debug the code paths that run for all
requests, not just authenticated/staff/superuser?
On 4/15/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
>
> Or even require a superuser?
>
> On Apr 16, 6:00 am, "Baptiste" <[EMAIL PROTECTED]> wrote:
> > Oh, and maybe we can chec
Or even require a superuser?
On Apr 16, 6:00 am, "Baptiste" <[EMAIL PROTECTED]> wrote:
> Oh, and maybe we can check if request.user.is_authenticated() and
> request.user.is_staff() before enabling it ?
>
> On 15 avr, 19:58, "Baptiste" <[EMAIL PROTECTED]> wrote:
>
> > I am +10 on this patch.
> > I
Oh, and maybe we can check if request.user.is_authenticated() and
request.user.is_staff() before enabling it ?
On 15 avr, 19:58, "Baptiste" <[EMAIL PROTECTED]> wrote:
> I am +10 on this patch.
> If this debugger was disabled if DEBUG is False, that wouldn't solve
> the problem ? I mean, are they
I am +10 on this patch.
If this debugger was disabled if DEBUG is False, that wouldn't solve
the problem ? I mean, are they people who use DEBUG mode in
production ?
On 14 avr, 15:38, Marek Kubica <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm bringing this question up again, as no decision has been ma
Hi,
I'm bringing this question up again, as no decision has been made.
The current state is:
- A AJAXy debugger could be useful. Some other frameworks have a
debugger, so it's not a useless gimmick.
- Having a debugger in the traceback is dangerous. We all agree
- Having the debugger enabl
Hello,
On Mon, 09 Apr 2007 12:19:18 -0700, Armin Ronacher wrote:
> Alright. Patch here: http://pocoo.org/~mitsuhiko/django_debugger.patch
> Screenshot here: http://pocoo.org/~mitsuhiko/djangodebug.png
That's definitely cool. There are cases in which you'd like to have a
prompt to check what went
Malcolm Tredinnick schrieb:
> Hi,
>
> On Mon, 2007-04-09 at 04:33 -0700, jedie wrote:
>> Why has django not a interactive AJAX traceback debugger?
>>
>> Using a interactive debugger you can play with objects at any point in
>> the error traceback.
>>
>> I known, a web shell is a open security h
Hoi,
Alright. Patch here: http://pocoo.org/~mitsuhiko/django_debugger.patch
Screenshot here: http://pocoo.org/~mitsuhiko/djangodebug.png
(Note, I edited those files in the same checkout I did the patches for
the __loader__ hook. So the patch is a bit bigger. Sorry for that)
Enable by adding ENA
If the only concern here is that debugging is a powerful feature that
needs to be carefully controlled, then surely a setting to enable it is
the right way to go? After all, many security experts will tell you
that the traceback handler we have now is a security hole, not because
it lets you e
Hi,
On Apr 9, 1:48 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Instead, it is triggered by whether or not DEBUG is True. Sometimes you
> want to have DEBUG=True in production environments, whether for just a
> little period of time -- to debug something -- or for longer. So I am
> relucta
Hi,
On Mon, 2007-04-09 at 04:33 -0700, jedie wrote:
> Why has django not a interactive AJAX traceback debugger?
>
> Using a interactive debugger you can play with objects at any point in
> the error traceback.
>
> I known, a web shell is a open security hole. But the interactive
> debugger shou
Why has django not a interactive AJAX traceback debugger?
Using a interactive debugger you can play with objects at any point in
the error traceback.
I known, a web shell is a open security hole. But the interactive
debugger should only running with the development Web server and if
debugging is
24 matches
Mail list logo
