[Zope-CMF] portal_membership.getRoster()

Norbert Marrale norbert@attira.com
Fri, 25 May 2001 02:51:36 +0200


On 23 May 2001, at 17:17, Shane Hathaway wrote:

> Norbert Marrale wrote:
> > 
> > On 23 May 2001, at 15:54, Shane Hathaway wrote:
> > 
> > > Norbert Marrale wrote:
> > > > On my local machine: a user who is not yet logged in, is redirected
> > > > to the login screen when trying to access the Members section. After
> > > > moving to the production server, this results in a browser login
> > > > window and an "Unauthorized" message with the following traceback.
> > >
> > > Enable the "List portal members" permission for Anonymous.
> > >
> > Doing so will allow anon users to view the roster, that's not what I
> > intended. In migrating the site I broke the friendly redirect to the
> > login_form method. Any newly added portal instance on the prod server
> > has this behavior, on my local machine everything seems to work fine and
> > the anon user is redirected as follows...
> > 
> > http://localhost:8080/blah/login_form?came_from=http%3a//localhost%3
> > a8080/blah/roster&retry=
> 
> Ah, I see what you're saying now.  Is the "auto login" property set on the
> cookie_authentication object?  Are cookies enabled in your browser? (Silly
> question but worth checking.)
> 
> Shane
> 

Checked that (and anything else I could think of)... No problems there 
either. Moved data.fs back from the production server to my local 
machine and as by magic, the redirect to login_form works again (?) 
Decided that the problem was machine/platform related until I saw this 
(new) piece of code in standard_topbar in the latest version of the 
generic skin:

<dtml-let member="portal_membership.getAuthenticatedMember()"
listMembers="portal_membership.checkPermission('List portal 
members', member)">
<dtml-if listMembers>`
<a href="&dtml-portal_url;/roster">members</a>&nbsp;
</dtml-if>
</dtml-let>

In my custom skin, based mostly on version 1.0 of CMF, the link to the 
member roster is created by <dtml-in "objectValues()">. I can obviously 
create a workaround based on checkPermission(), but still don't 
understand why I get different behavior from one machine to the other...
Does this change to the standard_topbar skin have anything to do with 
the erratic behavior? 

Next to different platforms, pages on my local machine are served 
through Medusa, while the production server uses PCGI. That's about 
all I can think of being different... I'm sorry to take your time on such a 
seemingly trivial issue, would much rather contribute to the workflow 
discussion (after all, that's why I installed the CVS version of CMF in 
the first place :)

Thanks again!

Norbert  


 





On the Road of Life, 
there are Tourists and there are Travelers.
I'd rather be Traveling!

Norbert Marrale
norbert@infocatch.com