[Zope-CMF] portal_membership.getRoster()

[seb bacon]

It's almost certainly a problem with the CookieCrumbler.  If you access
something to which you don't have permission, it's the CookieCrumbler
that is meant to intercept the Unauthorized exception and redirect you
to the login form.  Try debugging it a bit - check the __call__ method
of CookieCrumbler is being traversed.  Also, is the login_form
property filled in with the right destination?  Have you customized
the login form?  Perhaps you've missed out a </dtml-with> or
something, which breaks the redirect somehow? (I've noticed that
broken skins have very strange consequences).

seb

* Norbert Marrale <norbert@infocatch.com> [010525 01:55]:
> 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
> 
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
> 
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature requests

-- 

   [] j a m k i t 
           
        seb bacon
T:  020 7749 7218
F:  020 7739 8683
M:  07968 301 336
W: www.jamkit.com