[Zope] Sudden authentication problem

[Dunigan, Craig]

Thanks for the response, I was beginning to think I wasn't going to get one.

>  > which forces a login and points them to their home 
> folders, in a folder
>  > called "People."
> We do not see that a login is forced.
> But you are sure, it is?

Sorry, I missed the fact that the DTML method does not acquire permission
settings (explicitly unchecked in the management interface), and is only
viewable by an authenticated user.  *That* forces the login.
 
>  > ....
>  >     (Object: Catalog({'meta_type':'Yihaw Folder'}))
>  >   File 
> /opt/Zope/ZopeInst/lib/python/DocumentTemplate/DT_Util.py, line 334,
>  > in eval
>  >     (Object: 
> REQUEST['AUTHENTICATED_USER'].has_permission('Add EW Nav
>  > Links', REQUEST.resolve_url(BASE0+getpath(data_record_id_))))
>  >     (Info: BASE0)
>  >   File <string>, line 0, in ?
>  >   File 
> /opt/Zope/ZopeInst/lib/python/ZPublisher/HTTPRequest.py, line 724, in
>  > resolve_url
>  > Unauthorized: (see above)
> Your catalog contains something that can not be accessed by your user.

Hmm.  This seems likely.  I didn't write this site, I'm trying to pick up
after someone who left the company.  I honestly hadn't any idea what
"data_record_id" referred to.  From what you've said, I've done a little
more digging and found that it's the unique identifier which "getpath" needs
in order to find a cataloged object.  I had no idea the catalog was even
involved here, so this provides a whole new avenue to investigate.  Thanks!
 
>  > ...
>  > But from this, I read that AUTHENTICATED USER doesn't have 
> the permission
>  > 'Add EW Nav Links' (our own concotion, obviously)
> I do not think so.
> "Add EW Nav Links" is the permission that you want to test for.
> But the "Unauthorized" exception is already raised when
> the catalogued object is looked up.

Forgive my inexperience, but how do you know this?


>  > lacks that permission in 'BASE0+getpath(data_record_id),'  
> which I presume
>  > evaluates to the current folder?  Each user has a local 
> role of Manager in
>  > his/her own folder, which I thought is what the current 
> folder would be.
> Do you have a catalog in each of these folders or is there a
> global catalog. With a global catalog, it is well possible
> that it contains something inaccessible for some users.

Only one global catalog.  


> I do not know precisely, how "resolve_url" works.
> Maybe, it checks access rights on its way down to the object.
> Then, a folder to the object may not be accessible for your
> user.

That is exactly how "resolve_url" appears to behave to me.  It should be
checking through all objects in a folder hierarchy, and reporting which ones
the permission "Add EW Nav Links" exists for that user.  The loop is here:

<dtml-call "REQUEST.set('YihawFolders', [])">
<dtml-in expr="Catalog({'meta_type':'Yihaw Folder'})">
  <dtml-if "REQUEST['AUTHENTICATED_USER'].has_permission('Add EW Nav Links',
REQUEST.resolve_url(BASE0+getpath(data_record_id_)))">
    <dtml-call "YihawFolders.append(getpath(data_record_id_))">
  </dtml-if>
</dtml-in>

According to a Chris McDonough email in the archives, "resolve_url uses the
exact same publishing machinery as calling a URL
through the web; it does _not_ bypass the security machinery.  If you do not
have enough privledge to access to an object, then you will get an
Unauthorized, just like when you call it through the web."  Another bit I
did not know.  Now I can safely assume that there is a "Yihaw Folder"
somewhere in the site hierarchy that does not have appropriate permissions
set.  This also solves the mystery of how the problem was caused in the
first place.  I do know that my "technically challenged" co-worker was
creating some Yihaw folders yesterday.  It now appears to me that he made
one with incorrect permissions.  Am I thinking right here?  I'll check it
and see.

Thank you very much, Dieter!

Craig