X-Forwarded-For middleware
Hello,
I looked into the archives a bit, and it's been almost two years since
this subject was last brought up! So this periodic discussion is
probably overdue... I needed to change REMOTE_ADDR because some
components like django-request assume it represents the connected
user's address.
I want your input on the middleware below; it takes a list of trusted
proxies, and sets REMOTE_ADDR to the first untrusted address seen by
the outermost proxy. I took the same approach one takes in SMTP-land:
configure a list of trusted relays, and check the first Received:
header.
---8<--- middleware.py ---8<---
class ForwardedForMiddleware(object):
def __init__(self):
chain = []
try:
chain = settings.PROXY_CHAIN
except Exception, ex:
print >> sys.stderr, ex
self.reversed_proxy_chain = []
return
self.reversed_proxy_chain = list(reversed(chain))
def process_request(self, request):
if not 'HTTP_X_FORWARDED_FOR' in request.META:
return None
untrusted_addresses = list(reversed(
request.META['HTTP_X_FORWARDED_FOR'].split(',')
))
known_hosts = filter(
lambda (x, y): x == y.strip()
, zip(self.reversed_proxy_chain, untrusted_addresses)
)
print >> sys.stderr, self.reversed_proxy_chain, ':',
known_hosts, ':', untrusted_addresses
if not untrusted_addresses:
request.META['REMOTE_ADDR'] = known_hosts[-1][0]
else:
request.META['REMOTE_ADDR'] = untrusted_addresses[0]
---8<--- ---8<---
What do you think?
Thanks,
--
Luis Bruno
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: X-Forwarded-For middleware
On Tue, 2010-11-16 at 03:14 -0800, Luis Bruno wrote: > Hello, > > I looked into the archives a bit, and it's been almost two years since > this subject was last brought up! So this periodic discussion is > probably overdue... I needed to change REMOTE_ADDR because some > components like django-request assume it represents the connected > user's address. > > I want your input on the middleware below; it takes a list of trusted > proxies, and sets REMOTE_ADDR to the first untrusted address seen by > the outermost proxy. I took the same approach one takes in SMTP-land: > configure a list of trusted relays, and check the first Received: > header. It's not obvious what you are asking. We removed the SetRemoveAddrFromForwardedFor middleware for reasons described here: http://docs.djangoproject.com/en/dev/releases/1.1/#removed-setremoteaddrfromforwardedfor-middleware Are you asking for your middleware to go in to core to replace it? Luke -- "I spilled spot remover on my dog. Now he's gone." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
On Tue, 2010-11-16 at 11:34 -0300, Daniel Moisset wrote: > OK... after seeing a generally positive response (even if there's some > bikeshedding about the actual implementation which I don't care much > about, any of the proposals solve *my* problem ;-) ), how can this be > moved forward? I know the process that django changes follow, but I > don't know what's the process to change process :) (or who takes the > decision) > > Should I open a ticket about this proposal? Do open a ticket, because we need documentation patches for this, in the 'contributing' page. The current page says this: “worksforme” Used when the ticket doesn’t contain enough detail to replicate the original bug. That happens to be very similar to what we are proposing for 'needsinfo', so we at least need to think about how 'worksforme' is different. This will also require a change to Trac, which I for one don't know how to do (I don't see the configuration pages I would need in the Trac admin interface). My 2 cents on state vs resolution: If we go for a 'needsinfo' triage state, then at some point we will need to go and close ancient tickets which have 'needsinfo' and the original reporter has not provided it - presumably closing as INVALID. This will require some work to do (manual or scripted), and it may well be incorrect - we don't *know* that the report is invalid (according to our current definition), we just don't know enough to say it *is* valid. That pushes me in the direction of a 'needsinfo' resolution. We just have to remember to say 'Please re-open the ticket when the information has been provided' - and the 're-open' action is very obvious in Trac - more obvious than the 'Triage stage' box. Regards, Luke -- "I spilled spot remover on my dog. Now he's gone." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: X-Forwarded-For middleware
Dear Luke, On Nov 16, 1:12 pm, Luke Plant wrote: > It's not obvious what you are asking. We removed the > SetRemoveAddrFromForwardedFor middleware for reasons described here: > http://docs.djangoproject.com/en/dev/releases/1.1/#removed-setremoteaddrfromforwardedfor-middleware Thank you for plowing through my previous message; I'm not sure I'm fully aware of the reasons why it was replaced, but I read those release notes and these: * http://code.djangoproject.com/ticket/3872 * http://bob.pythonmac.org/archives/2005/09/23/apache-x-forwarded-for-caveat/ * http://code.djangoproject.com/ticket/9064 I think I can trust the X-Forwarded-For header added by my own proxy, and any X-Forwarded-For header added inside my infraestructure. I cannot trust the X-Forwarded-For headers already submitted by the client. I know that when a request arrives at a Django instance, it traversed these addresses: * end-user internal-IP * end-user "outside" address -- as seen by my proxy! * my own proxy Which is why the middleware I wrote above only considers pop()'ing the proxy stack as far as the addresses match the proxy-chain configured in ``settings.PROXY_CHAIN``. The first unmatching address gets into REMOTE_ADDR. > Are you asking for your middleware to go in to core to replace it? I thought I'd have a go at it, since I have this particular itch to scratch. As I said, SMTP has to deal with the same problem, and the way you do it is by: a) having a trusted list, and inspecting the first-untrusted address added by your own trusted relay. b) having the outside-facing machine remove any X-Real-Client-IP header and adding one herself with the REMOTE_ADDR as seen from her point of view. I chose a), altough Apache can be used / abused to do the X-Real- Client-IP trick. The code already Works On My Machine, but I need someone to test if it works when you have double internal proxying like: * * * If we can reach a rough consensus, I'll clean up the code a bit and try my hand at some unittesting. Thank you, and kind regards, -- Luis Bruno -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
country and states list in registration form
Hi All, Can anyone tell me if it is possible to get country and states(with OnChange option) list in registration form. I have created countries list but iam unable to get the states option regarded to the country. Is thr any way to do it. If anyone know plz help me -- View this message in context: http://old.nabble.com/country-and--states-list-in-registration-form-tp30231040p30231040.html Sent from the django-developers mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
On Tue, Nov 16, 2010 at 12:02 PM, Luke Plant wrote: > > Do open a ticket, because we need documentation patches for this Done, http://code.djangoproject.com/ticket/14702 Thanks for the feedback. Daniel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: country and states list in registration form
Take a look at how something similar was done using AJAX. http://www.nerdydork.com/dynamic-filtered-drop-down-choice-fields-with-django.html Hope that is helpful, if it isn't please give some examples. Sincerely, Michael --- On Tue, 11/16/10, hemi19 wrote: From: hemi19 Subject: country and states list in registration form To: django-developers@googlegroups.com Date: Tuesday, November 16, 2010, 12:29 PM Hi All, Can anyone tell me if it is possible to get country and states(with OnChange option) list in registration form. I have created countries list but iam unable to get the states option regarded to the country. Is thr any way to do it. If anyone know plz help me -- View this message in context: http://old.nabble.com/country-and--states-list-in-registration-form-tp30231040p30231040.html Sent from the django-developers mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
On Nov 15, 6:31 am, Russell Keith-Magee wrote: > On Mon, Nov 15, 2010 at 1:00 PM, Tai Lee wrote: > > I like the idea of needmoreinfo as a resolution, which makes it clear > > to the reporter that they need to take the next step to re-open the > > ticket with more info. I don't think that closed with "invalid" and a > > comment makes this as clear. > > > However, I think there's another problem area where we need to be able > > to make it clear that someone needs to take the next step, and that is > > when a ticket has been "accepted", feedback has been given to the > > reporter, and the reporter has actioned that feedback (e.g. by > > uploading a patch with tests and docs as per the feedback). In this > > case the ticket will often languish in "accepted" for months (or > > years). Since it is frowned upon for a reporter to mark their own > > ticket as RFC, there's no way for the reporter to flag the ticket as > > feedback actioned and put it back in the court of the original triager > > or core developer who accepted it and gave their feedback, who can > > then either push it up to RFC or commit it themselves. > > Incorrect. There *is* a way for a reporter to flag that they have > followed through on feedback -- they update the 'need docs', 'needs > tests' and 'needs improvement' flags. > > Example workflow: > > * Alice creates a ticket, with an incomplete patch (no tests, > incorrect implementation) > * Bob reviews the patch, marks it "Accepted, needs tests, patch needs > improvement" > * Alice updates the patch, adding tests (but not changing the > implemenation). She removes the two flags. > * Charlie reviews the patch, resets the 'patch needs improvement flag' > * Alice updates the patch, fixing the implementation. She removes the > needs improvement flag. > * Daisy reviews the patch, marks it RFC. > > At any point in this process, a search for tickets "Accepted & has > patch & !needs improvement & !needs docs & !needs tests" will reveal > tickets that need review of some kind. These tickets either need to be > moved to RFC, or need to have their flags set to indicate the > deficiency in the patch. I admit I am guilty of breaking the (unknown to me) rule/etiquette of marking my own tickets RFC as a last resort to move them forward. Unlike your example workflow, my experience is often like this: * I create a ticket and submit a patch plus passing tests (no need for docs if it's a bug or a promise to add them once it is reviewed and accepted, i.e. it passes the DDN stage). * The ticket stays unreviewed for days, weeks or months or it is marked as accepted at best, without actual feedback how to proceed, one way or another. * At some point I mark it RFC since as far as I am concerned it *is* ready for checkin. * More time passes and still nobody bothers. If I'm doing it wrong, please educate me. George -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: country and states list in registration form
On Nov 16, 6:29 pm, hemi19 wrote: > If anyone know plz help me Plz post usage question to django-users! Thx, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Doc. patch
Hi, I believe it is customary to politely ask for attention for bugs on this list. http://code.djangoproject.com/ticket/14704 Contains a minor patch to the documentation that would have saved me some headaches this afternoon. Klaas van Schelven -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Doc. patch
On Tue, Nov 16, 2010 at 5:18 PM, Klaas van Schelven wrote: > Hi, > > I believe it is customary to politely ask for attention for bugs on > this list. > > http://code.djangoproject.com/ticket/14704 > > Contains a minor patch to the documentation that would have saved me > some headaches this afternoon. OK, I just reviewed. Now you need to wait for the blessing of a core dev. D. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Doc. patch
On Tue, 2010-11-16 at 12:18 -0800, Klaas van Schelven wrote: > Hi, > > I believe it is customary to politely ask for attention for bugs on > this list. Well, if your ticket hasn't received the attention you think it deserves, then it is, but you waited less than 10 minutes from filing the ticket! People interested in new tickets already receive an e-mail about each one on django-updates, and we really don't need a post to django-developers as well. Thanks, Luke -- "I spilled spot remover on my dog. Now he's gone." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Doc. patch
On Nov 17, 10:10 am, Luke Plant wrote: > Well, if your ticket hasn't received the attention you think it > deserves, then it is, but you waited less than 10 minutes from filing > the ticket! Agreed, perhaps a bit hasty :) But in any case, I just committed it. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
Having recently set up a Trac installation for another project, I can tell you that making the actual change will require some hacking in the trac.ini file. There's no way to do it through the admin. All the best, - Gabriel On Nov 16, 7:02 am, Luke Plant wrote: > On Tue, 2010-11-16 at 11:34 -0300, Daniel Moisset wrote: > > OK... after seeing a generally positive response (even if there's some > > bikeshedding about the actual implementation which I don't care much > > about, any of the proposals solve *my* problem ;-) ), how can this be > > moved forward? I know the process that django changes follow, but I > > don't know what's the process to change process :) (or who takes the > > decision) > > > Should I open a ticket about this proposal? > > Do open a ticket, because we need documentation patches for this, in the > 'contributing' page. The current page says this: > > “worksforme” > Used when the ticket doesn’t contain enough detail to replicate the > original bug. > > That happens to be very similar to what we are proposing for > 'needsinfo', so we at least need to think about how 'worksforme' is > different. > > This will also require a change to Trac, which I for one don't know how > to do (I don't see the configuration pages I would need in the Trac > admin interface). > > My 2 cents on state vs resolution: > > If we go for a 'needsinfo' triage state, then at some point we will need > to go and close ancient tickets which have 'needsinfo' and the original > reporter has not provided it - presumably closing as INVALID. This will > require some work to do (manual or scripted), and it may well be > incorrect - we don't *know* that the report is invalid (according to our > current definition), we just don't know enough to say it *is* valid. > That pushes me in the direction of a 'needsinfo' resolution. We just > have to remember to say 'Please re-open the ticket when the information > has been provided' - and the 're-open' action is very obvious in Trac - > more obvious than the 'Triage stage' box. > > Regards, > > Luke > > -- > "I spilled spot remover on my dog. Now he's gone." (Steven Wright) > > Luke Plant ||http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
On Tue, Nov 16, 2010 at 12:02 PM, Luke Plant wrote: > > This will also require a change to Trac, which I for one don't know how > to do (I don't see the configuration pages I would need in the Trac > admin interface). > If you have the admin module ui enabled and TRAC_ADMIN permissions, you should see an admin link to the right displaying a dashboard with a "resolutions" link at the left where you can add ticket resolutions. If you don't... you should, it helps a lot :) Otherwise you'll need to add a row to a table in the trac db. Regards, D. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Doc. patch
The following two tickets are fairly trivial, with docs and tests, both accepted by a core dev 7 plus months ago. http://code.djangoproject.com/ticket/12398 http://code.djangoproject.com/ticket/13291 This one is 2 years old and has no docs (but I'm not sure if they are required). It was marked as DDN by Jacob who thought there was no bug, but subsequent comments seem to indicate that there is. It also has several dupes. http://code.djangoproject.com/ticket/8898 This one is a year old and needs a decision, but is fairly trivial so should not require too much debate to reach a consensus. http://code.djangoproject.com/ticket/11206 This one is also a year old, was accepted by a core committer, and I think I've addressed the feedback received to date. I'd appreciate it if anybody could review these tickets and provide further feedback on what action I need to take to get things moving again, make a decision or call for a vote on the DDN tickets, or to bump them up to RFC where appropriate. Cheers, Tai. On Nov 17, 8:36 am, SmileyChris wrote: > On Nov 17, 10:10 am, Luke Plant wrote: > > > Well, if your ticket hasn't received the attention you think it > > deserves, then it is, but you waited less than 10 minutes from filing > > the ticket! > > Agreed, perhaps a bit hasty :) > But in any case, I just committed it. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
I'm in favour of closing tickets with "need more info, re-open when you have it or if you disagree" because it clearly puts the onus back on the reporter to re-open the ticket after addressing the feedback in order to see any progress. Leaving tickets "open" with potentially yet another status or flag indicating that it needs some type of action will just contribute to the problem we already have with many tickets stagnating in some combination of "open" for literally years without any action. If a ticket is marked as "needs more info" while remaining open, it may be that only the original reporter (or somebody who is seriously motivated to dig) will be able to provide that more info, and if it's off their radar for whatever reason the ticket will likely remain in that state forevermore. Cheers. Tai. On Nov 17, 1:01 am, Andrew Godwin wrote: > It was ticket state, not closing state (sorry about the reply lag!). I > guess it's more that I don't like closing bugs purely because they've > not got enough information - it gives the wrong impression in my mind (I > only close once I have positive affirmation that it is invalid, > worksforme, etc.) > > This is, I suspect, more a relic of the way I use Trac. I'm fine with a > closing state as well, I just feel like closing tickets before we even > know what they are sends the wrong impression. > > On the other hand, we want to keep the trac as cruft-free as possible, > so I suppose closing tickets is fine in that regard. The ticket state > proposal has merit in that it can be crafted so that someone replying to > a ticket in needsinfo state moves it back into a "normal" state, thus > needing the minimum level of Trac competency from the reporter, and not > presenting a rather imposing "ticket closed!!!" interface - getting to a > project's ticket and finding it closed deters me from replying a lot > more than finding it in a "needsinfo" state. > > Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
This has been my experience, as well. I know this is an open source project and that we're all volunteers, but I have found it it extremely disheartening and a discouragement to further contribution when I have invested the time to do the right thing and submit a detailed report, with patch and docs and tests, and the tickets remain untouched or merely accepted without feedback (or without further feedback once initial feedback is addressed) for a prolonged period of time. Yes, it's possible to find tickets with many combinations of flags that need certain types of attention, but the big problem is that these tickets aren't being found. All the processes in the world won't help if at the end of the day we just say that sorry, nobody was interested in reviewing that particular combination, or a reviewer wasn't notified or failed to follow up on a ticket where they provided feedback that has been addressed and other reviewers simply left the ticket alone because they assumed that it would be reviewed again by the person who initially provided feedback. I think that while core committers are only volunteers as well, they should lead the community by example and follow up tickets that they have accepted, or provided feedback on, or simply accepted without feedback. Maybe trac can be improved in this respect by notifying reviewers when tickets that they have closed, or accepted, or provided feedback on, are updated. Cheers. Tai. On Nov 17, 6:17 am, George Sakkis wrote: > I admit I am guilty of breaking the (unknown to me) rule/etiquette of > marking my own tickets RFC as a last resort to move them forward. > Unlike your example workflow, my experience is often like this: > > * I create a ticket and submit a patch plus passing tests (no need for > docs if it's a bug or a promise to add them once it is reviewed and > accepted, i.e. it passes the DDN stage). > * The ticket stays unreviewed for days, weeks or months or it is > marked as accepted at best, without actual feedback how to proceed, > one way or another. > * At some point I mark it RFC since as far as I am concerned it *is* > ready for checkin. > * More time passes and still nobody bothers. > > If I'm doing it wrong, please educate me. > > George -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
