I do not believe this is enough for me (also, external methods do not implement the proxy mechanism).
 
I need to have some degree of confidence that the invoker of the method is not someone typing a URL at their browser, but rather, that the invoker is code I have written and hosted on the Zope instance.  I also need to be "relatively sure" that the protected code runs only after certain operations have been invoked, not at arbitrary points.
 
My current scheme involves explicitly adding a magic cookie (such as "itshot":"tabasco") to the request object in the invoker, and then looking for that cookie before executing "protected" code, in the method.
 
I skipped the idea of using an acl_users in the protected folder, and switching the current user to one of the authenticated users in the protected folder ... or simpler, to explicitly setting a more powerful role, because of the complexity of the code (I was lazy).
 
Thus, in http://zope/foobar.tal  I have <span tal:omit-tag="" tal:define="foo python:request.set('ishot','tabasco')"> ... use context.protected.method() .... </span>
 
And in http://zope/protected/method  I have something like:
 
if request.has_key('ishot'):
...
 
Your suggestion to use proxy roles implies a scheme whereby either http://zope/protected/method is called through another method that adds the appropriate role via its proxy mechanism, or is itself set to proxy to the required role.  The issue with this is that the proxy role is set at invoke time, instead of by logic within the method.
 
A.
 
-----Original Message-----
From: zope-admin@zope.org [mailto:zope-admin@zope.org] On Behalf Of Kevin Carlson
Sent: Thursday, December 26, 2002 9:44 PM
To: Andrew Athan; zope@zope.org
Subject: RE: [Zope] Idiom for accessing restricted capabilities

Sounds like you should use a proxy role for the methods in question.
 
Kevin
-----Original Message-----
From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Andrew Athan
Sent: Thursday, December 26, 2002 6:47 PM
To: zope@zope.org
Subject: [Zope] Idiom for accessing restricted capabilities

 
Say you have a site which must perform certain restricted activites, but those activities should be invokable by anonymous users IF AND ONLY IF the users initiate them from an authorized source (e.g., a specific DTML or ZPT script)...what is the recommended way of setting this up?
 
Example:  Site X allows anonymous users to purchase an item.  The purchase() method is defined to be accessible only by a specific trusted/authenticated user.  The purchase() method should not be invokable by the anonymous user, but if the anonymous user access the checkout page template, that page template should be able to invoke purchase().
 
Now, say I want to invoke purchase() from an ExternalMethod that is called from an anonymous context, what's the preferred way of setting and supplying the appropriate credentials?
 
I have solved these problems "my way," think the solution is hairy and dirty, and would therefore like to see what people's recommended solutions are.
 
A.