Forum OpenACS Development: Re: Registered users can read private procs in api-doc

Posted by Gustaf Neumann on
Thanks for reporting a problem with the bug-tracker ... which was not easy to fix: the problem was that the vulnerability scanner has semi-inserted some values into the bugtracker, which blocked the generation of new entries.

One problem with the bug-tracker is the way, how it determines the names of the cr-items, which is very crude (and as this example shows) not fail-safe. One other problem is, that this semi-insertion should not be possible....

However, i have fixed the contents in the database, fixes a few other minor issues and modernized the SQL procedures and functions to make these more readable. Let us hopwe, this works for the next ten years.

Concerning your question: the "private" modifier of ad_procs has nothing to do with security. It can be called from every other package, it can be introspected, etc. The only purpose it has for ad_procs is to denote a developer an intended usage.

btw. it is not correct that xotcl/nsf objects are "procs", these are tcl commands (c-implemented functions).

What kind of problem are you addressing? Do you have passwords etc. in your ad_procs? The easiest thing is then do restrict the access to the API-browser to admins/swas or whatever is appropriate.

Posted by Benjamin Brink on
Gustaf, if ever there were an Olympic competition for debugging, surely you would win at least ten years of Gold. Thank you.

And thank you for correcting my wild and reckless expression of xotcl objects; The falsehood is proof that my casual interpretation of xotcl snippets in context of generic tcl is not a practical method of learning.

Also, I'm sorry you felt it necessary to repeat to me how the "private" modifier of ad_proc is not for security. The previous time, I was trying to hide some code from other parts of the system.

What kind of problem are you addressing?

In this second case, I'm trying to find a long-term, stable compromise between:

1. integrating ad_proc's api-doc documentation with package documentation published via /doc

2. hiding some site installation specific modified security code so non-admins/swas cannot read it. Yeah, a more complex scenario of passwords in ad_procs;

Instead of passwords, its code that encrypts sensitive user info stored for use in context of the system that must occasionally be decrypted again (instead of the usual comparing of one-way algorithms).

You are right, the current solution is to limit access of /api-doc to admins (on an ecommerce site for example), and publish generic documentation accessible to all users on another site (such as

This is acceptable, if I am the only one using this new ecommerce package. However, the package is intended for others.

As a package developer, I would be remiss if I didn't at least try to find a way to have an equivalent solution incorporated into OpenACS by default, since the cost of changing a system after deployment for just one case might be so much higher than overcoming the hurdle of adding a subtle revision to OpenACS to begin with.

Also, it would be convenient if sensitive code could be hidden on early adopting sites while providing a reasonable amount of api documentation that helps promote the package. --a way to promote OpenACS and packages without duplication in resource costs etc.

As I type this, I think I figured out a fallback solution:

Add some code to a tcl/sched-init.tcl file that checks permissions for api-browser, and forces admin access only. (And make a separate site to promote app.)

Other ways I thought about exploring:

A. define the procs outside of ad_proc, or as apps outside of OpenACS.
B. add a "hide" argument to ad_proc so API browser doesn't publish to non-admins.

I supose option B would have too much impact on the system to consider adding to OpenACS even if a patch is submitted (subject to refactoring).

Posted by Benjamin Brink on
The solution is to assign the encrypt and decrypt proc names to a parameter which gets called by safe_eval. That way, the procs may be something other than the default ones included in the package.