Improve is_anonymous docs to warn about Zope security model in __init__
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 101
- Forks
- 62
- Avg merge
- 15h 15m
- Merged PRs (30d)
- 1
Description
We just came by this issue this morning (change getAuthenticatedUser to is_anonymous):
I'm making a View with customized traversal. I want to traverse to next object dynamically base on current logged in user. But all method I know (portal_membership.getAuthenticatedUser, portal_state.member etc..) always return anonymous on View object's init and publicTraversal. The only case they return right is in object's call. What should I do to make getAuthenticatedUser work on my case (either on view's init or publicTraversal call)?
@mjpieters gave an impecable answer:
You can't. Due to Zope's security model, the user is determined after traversal, because this information depends on the context of the published object. You can only rely on getAuthenticatedUser when the object is being published; after traversal, authentication and authorization take place, and then publication, which in views means invoking the call method. Because publicTraversal is called as part of the traversal stage, you cannot know the authenticated user in that method either. You'll have to re-think your view to not rely on the authenticated user being known during that stage.
Since this is at Zope level and trying to add a WARNING or something like that when we're trying to get the user in __init__ is not possible, would it be the case to at least add a warning to plone.api docs (and the method docstring as well) and portal_membership method itself?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the is_anonymous documentation and method docstring in plone.api, then inspect the portal_membership method mentioned in the issue. Document that the authenticated user is unavailable during init and publicTraversal because authentication follows traversal, while call can rely on it. Done means the warning is present in the relevant API documentation and docstrings.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- authentication, documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100