1.5 -- test_json in test_identity

[Ken Kuhlman]

Does anyone see the problem behind the failing 1.5 test?  In test_identity, it's test_json.

So far it's eluding me..

thanks,
-Ken


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@...
To unsubscribe from this group, send email to turbogears-trunk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christopher Arndt]

Ken Kuhlman wrote:
> Does anyone see the problem behind the failing 1.5 test?  In test_identity,
> it's test_json.
>
> So far it's eluding me..

These are the lines of the test where it is failing:

         response = self.app.get('/json', status=403)
         # we get the output of the identity_failure controller in this case
         assert 'identity_failed_answer' in response, response
         response = self.app.get('/json?tg_format=json', status=403)
         # we get the right status code, but not the output of
identity_failure
         assert 'identity_failed_answer' not in response, response.body

The second to last assert fails, because the response is
'identity_failed_answer', which means the method set for idenity failure
URL was called (IdentityRoot.identity_failed). The test seems to imply
that this should not happen, when using 'tg_format=json' in the URL and
the config setting 'tg.allow_json=False' is set (as done in the
testcase's setUp method). I'm not sure what correct behavior is in this
case, maybe Chris Zwerschke, who wrote this test, can shed some light on
this?

Chris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@...
To unsubscribe from this group, send email to turbogears-trunk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Ken Kuhlman]

On Wed, Nov 4, 2009 at 3:43 PM, Christopher Arndt <chris.arndt@...> wrote:

Ken Kuhlman wrote:
> Does anyone see the problem behind the failing 1.5 test?  In test_identity,
> it's test_json.
>
> So far it's eluding me..

These are the lines of the test where it is failing:

        response = self.app.get('/json', status=403)
        # we get the output of the identity_failure controller in this case
        assert 'identity_failed_answer' in response, response
        response = self.app.get('/json?tg_format=json', status=403)
        # we get the right status code, but not the output of
identity_failure
        assert 'identity_failed_answer' not in response, response.body

The second to last assert fails, because the response is
'identity_failed_answer', which means the method set for idenity failure
URL was called (IdentityRoot.identity_failed). The test seems to imply
that this should not happen, when using 'tg_format=json' in the URL and
the config setting 'tg.allow_json=False' is set (as done in the
testcase's setUp method). I'm not sure what correct behavior is in this
case, maybe Chris Zwerschke, who wrote this test, can shed some light on
this?

Chris

Thanks for the response, Chris.

I'm still going in circles on this, but they're getting tighter.  If they don't reach an end-point in the next 48 hours or so, I'll open a new ticket for the regression (referencing #2036 & #1985), and tag that line with a FIXME so that it's out of the way.

I'm getting to the point where it's tempting to dust off Florent's wsgi version of identity & bypass the nested decorators & generics in controllers.py.   But that might just be the frustration talking; time will tell.

-Ken

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@...
To unsubscribe from this group, send email to turbogears-trunk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christopher Arndt]

On 5 Nov., 20:02, Ken Kuhlman <kskuhl...@...> wrote:
> I'm still going in circles on this, but they're getting tighter.  If they
> don't reach an end-point in the next 48 hours or so, I'll open a new ticket
> for the regression (referencing #2036 & #1985), and tag that line with a
> FIXME so that it's out of the way.
>
> I'm getting to the point where it's tempting to dust off Florent's wsgi
> version of identity & bypass the nested decorators & generics in
> controllers.py.   But that might just be the frustration talking; time will
> tell.

You should try asking C. Zwerschke for help. He understands that
generic function and decorator stuff far better than me.

Chris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@...
To unsubscribe from this group, send email to turbogears-trunk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christoph Zwerschke]

Christopher Arndt schrieb:
> I'm not sure what correct behavior is in this case, maybe Chris
> Zwerschke, who wrote this test, can shed some light on this?

Sorry, I see this only now. Will have a look at it today.

-- Christoph

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@...
To unsubscribe from this group, send email to turbogears-trunk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christoph Zwerschke]

I found the cause of the failing test_json test in test_identity.

As ChrisA pointed out, the test checks that there is a proper error
when using 'tg_format=json' in the URL and
the config setting 'tg.allow_json=False'. Because the json() method is
protected, it redirects to identity_failed(). Since
tg.allow_json=False and identity_failed() does not explicitly allow
json, it should not render any output but give a "forbidden" error (if
it was not protected it should have given a "not found" error).

The problem was that the redirect from json() to identity_failed() is
accomplished by an internal redirect, and in CherryPy 3 parameters are
not redirected any more automatically for internal redirects.
Therefore, the tg_format=json parameter was not redirected, so
identity_failed() happily produced html output. My fix was to manually
append the query string to the url in the internal redirect.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@...
To unsubscribe from this group, send email to turbogears-trunk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Ken Kuhlman]

On Fri, Nov 6, 2009 at 8:54 AM, Christoph Zwerschke <cito@...> wrote:

I found the cause of the failing test_json test in test_identity.

As ChrisA pointed out, the test checks that there is a proper error

when using 'tg_format=json' in the URL and

the config setting 'tg.allow_json=False'. Because the json() method is
protected, it redirects to identity_failed(). Since
tg.allow_json=False and identity_failed() does not explicitly allow
json, it should not render any output but give a "forbidden" error (if
it was not protected it should have given a "not found" error).

The problem was that the redirect from json() to identity_failed() is
accomplished by an internal redirect, and in CherryPy 3 parameters are
not redirected any more automatically for internal redirects.
Therefore, the tg_format=json parameter was not redirected, so
identity_failed() happily produced html output. My fix was to manually
append the query string to the url in the internal redirect.

You rock!  Thank you so much for fixing this!

-Ken


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@...
To unsubscribe from this group, send email to turbogears-trunk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---