ForbiddenAttribute exception raised changing property of object

A similar OOPS happened: OOPS-1488EA884, this time using the anonymous Launchpad object.

To reproduce:

>>> anon_lp = Launchpad.login_anonymously('foo')
>>> ubuntu = anon_lp.distributions['ubuntu']
>>> lucid = ubuntu.getSeries(name_or_version='lucid')
>>> sp = lucid.getSourcePackage(name='gcc-defaults')
>>> lp_project = anon_lp.projects['launchpad']
>>> devel_series = lp_project.getSeries(name="devel")
>>> sp.productseries = devel_series
>>> sp.lp_save()
HTTPError: HTTP Error 500: Internal Server Error
Response body:
---
ForbiddenAttribute

<matsubara> leonardr, so, I think this is an OOPS that came up a few weeks ago and is probably related to the fact the user is anonymous and trying to do a write operation. shouldn't the user get another kind of error? or the app not record such errors as oopses?
<leonardr> matsubara, i'm looking
<matsubara> leonardr, hmm maybe it's the same as bug 271029
<leonardr> the user should certainly get a 401 in any situation where they try something they don't have permission for
<leonardr> but it might be difficult to get to that point
<matsubara> I mean, not same but similar enough to have the same fix. (clearly they're changing differnt attributes)
<leonardr> i'm not sure if this will get rid of the oops, but we could set the http_error for ForbiddenAttribute to 401
<matsubara> do you think https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1488EA884 is the similar enough to the one described in bug 271029? shall I add that oops to the bug report or file a new bug report?
<leonardr> matusbara: i think you should add it, since i propose a solution that will hopeflly get rid of both OOPSes
<leonardr> but i don't know how an OOPS is triggered. is it triggered by an unhandled exception?
<matsubara> yes
<matsubara> I wonder how that one was triggered though.
<matsubara> hmm
<matsubara> actually there's a difference between a distro SP and a SP
<matsubara> ok, successfully reproduce
<matsubara> I'll add the steps to the bug report

This bug was probably fixed by my recent change to the error handling code. ForbiddenAttribute exceptions now result in a 401 response code.

Just to be clear, "probably fixed" means I'm speculating as to what fixed it. It's definitely fixed.