Forum OpenACS Development: How to do sessions
I had an extremely hard time trying to figure out how to extend the login and registration system for my needs, so I decided to roll my own (it was either that or move to another product). So this was my approach, which seems to be "working" (cough). You can look at it and give feedback before I ask my question.
1. Made my own "users" database table.
2. Added a test user to the table by hand.
3. Made a login screen (adp/tcl). The login screen simply does a database select on username/password and redirects to the "logged in" screen on success, or "error" screen on failure.
At any rate, now I would like sessions. If I had extended the openACS login/registration, I guess this would have been automatic, but that's not happening. Is this reasonably easy to do "by hand?" Can someone point me to resources (API calls and what not)?
There really isn't much benefit to using OpenACS without the users login and security system. By writing your own you can also introduce security issues that have been discovered and resolved over 10 years of use.
If you want to extend the information you collect on registration this should not be too hard. The first question is what version of OpenACS are you using. From there I can recommend the best solution.
If you want to understand how sessions work you should review under openacs-4/packages/acs-tcl/tcl/security-procs.tcl.
The version I'm running is the latest version for Windows. I'm just using the Windows version for test and development. I planned on moving everything to unix for production.
There's a few different ways to extend registration.
One low tech way is used by ecommerce, where registration is followed by a redirect to checkout.
There's also a way where you can create a user using the API directly.
I'm sure Dave will explain how to approach extending the registration page directly --I haven't done that, so can't help there.
ad_form is used for building dynamic forms. If you're like me and find that too abstract, having too many limitations, or requiring a high learning curve to be of value, then there's an alternate method which will soon be available that uses a tcl styled API to build forms. The learning curve for this new way is low, because it depends on knowing html forms and tcl, not much else. I am debugging/alpha testing it now and will post when it reaches beta.
I did make a form already using ad_form. Actually, I didn't find it *too* bad - documentation and a walk-through were readily available. Some things that weren't documented took some time to figure, but at least they were "reasonably figure-able." Still, better is always, well, better, so I look forward to seeing your new forms!
Hope Dave or somebody can help me out with the other stuff.
The question is if your acs-kernel is 5.6.0. You can check this by visiting the URL /acs-admin/apm/ under your installation and checking the version number for the acs-kernel package.
If this is the case, I am working on a tutorial for customizing a subsite that would be perfect to help you. If you are using a version older than 5.6.0 the techniques are different.
I am working on the tutorial for this, I'll see if I have something that will help you.
I would go with the latter approach. Also, if for some reason I needed to write my own user tracking code complete with users table, etc. (e.g., for an entirely different system), I would certainly read the OpenACS code, make sure I understand why it's doing things, and then use it as a model.
So you are right - I'm outta here. This is the last post I will bother you people with.
I've many times had that "this is junk" feeling when staring at a big pile of foreign code that I wanted to make do something new, but more often than not, as I learned how it actually worked, I realized it wasn't junk at all. Modifying and refactoring old known-working code never sounds as much fun as writing something new "from scratch", but it's usually the more effective approach. (You're unlikely to really understand the problem until you've worked with the old code.) This is only more true when the existing code is both battle tested and friendly to modification, like OpenACS.
Taking a rather large toolkit like OpenACS, and then deciding to write your own users table from scratch, is, as anything other than an academic or tutorial exercise, a pretty strange approach. OpenACS's single biggest strength is arguably its well thought-out data model, so totally ignoring a core part of it like the users table makes no sense.
You'd probably have been better off explaining what custom behavior you want your site's "login and registration system" to have, and how you're having trouble using OpenACS to do it. Since you didn't tell anyone what your actual goal is, you're a lot less likely to get the advice that would be most effective in solving your problem.