ISpecification.all_specifications returns an empty list for anonymous users of the API
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Launchpad itself |
High
|
Guilherme Salgado |
Bug Description
Apps accessing the API anonymously will always get an empty list from .all_specifications and .valid_
The same happens on ISpecification.
Related branches
- Jelmer Vernooij (community): Approve on 2010-12-01
-
Diff: 141 lines (+50/-1)5 files modifiedlib/canonical/launchpad/security.py (+15/-1)
lib/lp/blueprints/interfaces/specification.py (+1/-0)
lib/lp/blueprints/tests/test_webservice.py (+16/-0)
lib/lp/testing/__init__.py (+1/-0)
lib/lp/testing/_webservice.py (+17/-0)
description: | updated |
Guilherme Salgado (salgado) wrote : | #1 |
William Grant (wgrant) wrote : | #2 |
lazr.restful is hardcoded to check for launchpad.View before returning something in a collection. But it respects the defined permissions (in this case zope.Public) when determining which attributes to return from a named operation.
Guilherme Salgado (salgado) wrote : Re: [Bug 683106] Re: ISpecification.all_specifications returns an empty list for anonymous users of the API | #3 |
Ok, so I take that it is known that to expose a collection of ISomething
on the API you need to make sure there is a launchpad.View security
adapter for it?
In the case of ISpecification, I think it makes sense for that security
adapter to allow unrestricted (read-only) access given that all
blueprints are public anyway.
Changed in blueprint: | |
assignee: | nobody → Guilherme Salgado (salgado) |
status: | In Progress → Fix Committed |
Fixed in stable r12011 <http://
Changed in blueprint: | |
milestone: | none → 10.12 |
tags: | added: qa-needstesting |
tags: |
added: qa-ok removed: qa-needstesting |
Changed in blueprint: | |
status: | Fix Committed → Fix Released |
Leonard believes this is a permission issue:
<leonardr> salgado: lazr.restful does an explicit permission check to filter items from a collection. it does not do an explicit check on the return value of a named operation--it relies on zope throwing an exception
<leonardr> we might have a situation where an explicit permission check fails but the permission is never enforced?
(that would explain why we can get specs anonymously via getSpecification() but not via all_specifications)