We have two problems that are similar, but would like handled in two different ways. I have been using django for a few months modifying and adding to an existing app and have a pretty good feel for how most of the framework fits together, but some parts still baffle me, like error handling (even after reading some of the django source)
The first thing that I would like to do is something special when an error comes up (all except security errors, i would like to handle those differently, but it may fall along the same lines.) Right now when you are in debug mode, it takes over the entire screen with the wonderful traceback and other debugging info. This is great, except I loose all of my navigation framework. How can I get that wonderful traceback info without losing navigation? I use no frames for the navigation, they are part of the base templates. If I had access to the html of the error page, i would likely strip out the <head></head><title></title> and <body></body> tags and put it into my own error template that just populates the content block. Part two of this first problems (which I will probably be able to do more easily once i determine the first part) is to when not in debug mode (we could even create our own unique variable to use to determine this), but basically when we are in production mode, we want that entire traceback page, but not in a way a user can understand it. Something simple they can either download and save and send to use, or copy and paste into an e-mail address to us. I might just base64 it would be good enough and then do the reverse on our side to see what their problem was. We might also include some extra debugging information to try and tell what they were doing right before this (we have a bread crumb system already in place we can pull from) to help us debug the problem. Problem two is when clicking on some objects that should not have been shown (We are going to fix the show/not show part that are obvious, but there may be more subtle errors that are harder to catch). Anyway, the clickable link is there, but instead of raising a security traceback, it will do one of two things. 1. Send the user back to the logon page with no reason why they were sent there. They are then confused because typing in their correct username and password will send them right back here because /?next=problem/security/page. Oh, and they are actually still logged in because if you click back, or go to a page they have access to, all is good. 2. A page that just displays something like "you are not allowed to do that" (can't remember the exact wording) This is just about as bad since they have no opportunity to log it, they can use the back button, like they could above, but they also lose the navigation framework. For these errors, I am hoping to have a spot in the base template that can display an errors and basically send the user back to the page where they had the ability to click/post to the problem page and display and error on that page that doing that again will cause a security error with as much info as I can display to help them in that situation. I know about the process_exception middleware method, but it only handles view exceptions, not the selection of URLs or security problems. It looks like security errors are even swallowed by the URL handling code so I don't have any control. I could be misreading the code. Anyone have any ideas how I can solve even one of these problems? Thanks. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
