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

Collapse
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 OpenACS.org).

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).