Re: User data being exposed with mod_wsgi/apache

2011-11-01 Thread Jennifer Bell
Well... you were right.  The problem was with my code.  As a public
service, the code below will expose the data of a logged in user for
anyone viewing the site:

BAD code >

view.py:

def show( request, report_id ):
report = get_object_or_404(Report, id=report_id)
return render_to_response("reports/show.html",
{ "report": report,
  "update_form": ReportUpdateForm(user=request.user),
context_instance=RequestContext(request))

form.py:

class ReportUpdateForm(forms.ModelForm):

class Meta:
model = ReportUpdate
fields = ('desc','author','email','phone','is_fixed')

def
__init__(self,data=None,files=None,initial={},first_update=False,user
= None, report=None):
   if user and user.is_authenticated() and
UserProfile.objects.filter(user=user).exists():
   initial[ 'author' ] = user.first_name + " " +
user.last_name
   initial[ 'phone' ] = user.get_profile().phone
   initial[ 'email' ] = user.email
   super(ReportUpdateForm,self).__init__(data,files=files,
initial=initial)


>

... I'm guessing because the 'initial' declaration in the form
constructor prototype is not on the stack, like I would have thought.
Changing the view to construct the ReportUpdateForm like so:

  "update_form": ReportUpdateForm(user=request.user,
initial={}),

puts the values on the stack, instead of in the apparently persistent
dict declared in the constructor prototype.  This was confirmed with a
unit test:

>

def test_update_form(self):
# check that default values are already filled in.
c = Client()
r = c.login(username='user1',password='user1')
url = '/reports/4'
r = c.get( url )
self.assertEquals( r.status_code, 200 )
self.assertContains(r,"Clark Kent")
self.assertContains(r,"us...@test.com")
self.assertContains(r,"555-111-")

# check that default values are NOT already filled in
# for a second anonymous client (problem in the field)

c2 = Client()
r = c2.get( url )
self.assertEquals( r.status_code, 200 )
self.assertNotContains(r,"Clark Kent")
self.assertNotContains(r,"us...@test.com")
self.assertNotContains(r,"555-111-")

--->

Which passes or fails according to the change above.   Thank you for
your advice.

Jennifer


On Oct 25, 2:36 pm, Daniel Roseman <dan...@roseman.org.uk> wrote:
> On Monday, 24 October 2011 23:14:40 UTC+1, Jennifer Bell wrote:
>
> > On my site, some user data is automatically filled in to a form if a
> > user is logged in by accessing request.user in the view code.
>
> > On deployment, it seems that if *any* user is logged in, forms
> > requested via another browser will be filled in with their data.  The
> > data is not filled in if no user is logged in.
>
> > I'm mystified.  Where is this coming from?  I'm using django 1.3, and
> > caching is not enabled in my settings (though I have set
> > CACHE_MIDDLEWARE_ANONYMOUS_ONLY=True just in case).
>
> > The WSGIDeamonProcess is set up like this:
> > WSGIDaemonProcess lalala user=lalala group=lalala threads=1
> > processes=3
>
> > Is this apache?  mod_wsgi?
>
> > Jennifer
>
> No, it's your code. You've got something somewhere that's providing default
> arguments to your form, but is doing so at the module or class level rather
> than per-request. You'd better show your form and view code.
> --
> DR.

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



User data being exposed with mod_wsgi/apache

2011-10-24 Thread Jennifer Bell
On my site, some user data is automatically filled in to a form if a
user is logged in by accessing request.user in the view code.

On deployment, it seems that if *any* user is logged in, forms
requested via another browser will be filled in with their data.  The
data is not filled in if no user is logged in.

I'm mystified.  Where is this coming from?  I'm using django 1.3, and
caching is not enabled in my settings (though I have set
CACHE_MIDDLEWARE_ANONYMOUS_ONLY=True just in case).

The WSGIDeamonProcess is set up like this:
WSGIDaemonProcess lalala user=lalala group=lalala threads=1
processes=3

Is this apache?  mod_wsgi?

Jennifer

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: automated testing: how to generate human-verifiable views?

2011-01-06 Thread Jennifer Bell

Sorry if I confused people... I'm still looking for some feedback.
Really, I guess I just want to streamline CSS/layout/language/browser
testing so problems that commonly occur aren't discovered on the final
round of staging testing.

I imagine a test series like:

[ {
  series_name: payroll_screens,
  urls:  [ url1,url2... ]
  fixtures: payroll.json, employees.json
  },
...
]

And through a test url that puts a 'next/prev' widget somewhere like a
top bar, iterates through the urls (in an iframe?) while loading and
unloading fixtures.

Is this a really weird thing to want to do?  You can TDD almost
everything else in django through TestClient except for the end result
of how stuff looks.

Jennifer


On Jan 4, 6:21 pm, Jennifer Bell <jenniferlia...@yahoo.ca> wrote:
> OK, to elaborate: I have a open source project with consistent pain
> points around css and browser testing.  Example concrete issues for
> this project are a) multi-language support, as varying text length
> will often throw off the aesthetics of the layout, and b) recently, a
> mysterious failure in geodjango google-map drawing where in some
> corner-cases, the map silently fails to draw.
>
> Really, I'm looking for a framework for a human tester to be able to
> look at a sequence of html pages generated with different test data in
> the database.  I want the tester to be able make a 'pretty/ugly/
> horribly wrong' call without having to do a bunch of clicking or data
> entry.  Ideally, they would just click 'next' on some widget, which
> would pull up the next URL/test db combination.
>
> Jennifer
>
> On Jan 4, 5:18 pm, Nick Stinemates <nstinema...@gmail.com> wrote:
>
> > Can you elaborate a bit?
>
> > Are you interested in having the ui render and generate a screen shot
> > for human review? That's how I interpreted your question. If that's
> > the case, look in to generating a screenshot by leveraging a tool that
> > generates a png from HTML.
>
> > I am eager to hear what others think.
>
> > Nick
>
> > On Tuesday, January 4, 2011, Jennifer Bell <jenniferlia...@yahoo.ca> wrote:
> > > Hi,
>
> > > I'm trying to figure out the best way of doing something I'd like
> > > to partially automate staging testing by generating a sequence of
> > > human verifiable views, with the goal of making sure my app views/css/
> > > 3rd-party javascript etc. are drawing the way they ought to in more
> > > complicated scenarios.    While back end code can easily be tested
> > > with TestClient, failures in the 'final mile' of rendering are really
> > > annoying.
>
> > > It would be nice to have a 'view test mode' that allows a tester to
> > > click through a series of database configuration / URL pairs in a
> > > relatively painless way.
>
> > > Is there a standard way of doing this, or any existing modules I could
> > > use to achieve this?
>
> > > Jennifer
>
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Django users" group.
> > > To post to this group, send email to django-us...@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > django-users+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: automated testing: how to generate human-verifiable views?

2011-01-04 Thread Jennifer Bell

OK, to elaborate: I have a open source project with consistent pain
points around css and browser testing.  Example concrete issues for
this project are a) multi-language support, as varying text length
will often throw off the aesthetics of the layout, and b) recently, a
mysterious failure in geodjango google-map drawing where in some
corner-cases, the map silently fails to draw.

Really, I'm looking for a framework for a human tester to be able to
look at a sequence of html pages generated with different test data in
the database.  I want the tester to be able make a 'pretty/ugly/
horribly wrong' call without having to do a bunch of clicking or data
entry.  Ideally, they would just click 'next' on some widget, which
would pull up the next URL/test db combination.

Jennifer

On Jan 4, 5:18 pm, Nick Stinemates <nstinema...@gmail.com> wrote:
> Can you elaborate a bit?
>
> Are you interested in having the ui render and generate a screen shot
> for human review? That's how I interpreted your question. If that's
> the case, look in to generating a screenshot by leveraging a tool that
> generates a png from HTML.
>
> I am eager to hear what others think.
>
> Nick
>
> On Tuesday, January 4, 2011, Jennifer Bell <jenniferlia...@yahoo.ca> wrote:
> > Hi,
>
> > I'm trying to figure out the best way of doing something I'd like
> > to partially automate staging testing by generating a sequence of
> > human verifiable views, with the goal of making sure my app views/css/
> > 3rd-party javascript etc. are drawing the way they ought to in more
> > complicated scenarios.    While back end code can easily be tested
> > with TestClient, failures in the 'final mile' of rendering are really
> > annoying.
>
> > It would be nice to have a 'view test mode' that allows a tester to
> > click through a series of database configuration / URL pairs in a
> > relatively painless way.
>
> > Is there a standard way of doing this, or any existing modules I could
> > use to achieve this?
>
> > Jennifer
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



automated testing: how to generate human-verifiable views?

2011-01-04 Thread Jennifer Bell
Hi,

I'm trying to figure out the best way of doing something I'd like
to partially automate staging testing by generating a sequence of
human verifiable views, with the goal of making sure my app views/css/
3rd-party javascript etc. are drawing the way they ought to in more
complicated scenarios.While back end code can easily be tested
with TestClient, failures in the 'final mile' of rendering are really
annoying.

It would be nice to have a 'view test mode' that allows a tester to
click through a series of database configuration / URL pairs in a
relatively painless way.

Is there a standard way of doing this, or any existing modules I could
use to achieve this?

Jennifer

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Admin two-field ordering resorted by table template: way to turn off?

2009-12-09 Thread Jennifer Bell
I would like my objects to be ordered by two (or more) fields when
viewed in the admin changelist.  However, I noticed that ordering only
works for the first field listed.

I'm pretty sure this is because the order of the objects given to the
template is overridden by the javascript sort in the default admin
changelist template.  Is there any way I can turn this off without
modifying admin templates in the django install?

Jennifer

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.